On 14/03/2015 01:20, Harald Becker wrote:
I'm using none blocking I/O and expect handling of failure situations, e.g writing into pipe fails with EAGAIN: poll wait until write possible with timeout. then redo write
Hm, after checking, you're right: the guarantee of atomicity applies with nonblocking IO too, i.e. there are no short writes. Which is a good thing, as long as you know that no message will exceed PIPE_BUF - and that is, for now, the case with uevents, but I still don't like to rely on it.
Laurent, you still stuck on netlink! Using named pipe is requirement for the hotplug helper stuff, how else should they get access to the pipe, when not using a named pipe? And what is the difference between fifos and pipes?
I call "pipe" an anonymous pipe. And an anonymous pipe, created by the netlink listener when it forks the event handler, is clearly the right solution, because it is private to those two processes. With a fifo, aka named pipe, any process with the appropriate file system access may connect to the pipe, and that is a problem: - for writing: why would you need another process to write into the pipe ? You have *one* authoritative source of information, which is the netlink listener, any other source is noise, or worse, malevolent. - for reading: having several readers on the same pipe is the land of undefined behaviour. You definitely don't want that. - generally speaking, fifos are tricky beasts, with weird and unclear semantics around what happens when the last writer closes, different behaviours wrt kernel and even *kernel version*, and more than their fair share of bugs. Programming a poll() loop around a fifo is a lot more complicated, counter-intuitive, and brittle, than it should be (whereas anonymous pipes are easy as pie. Mmm... pie.) I'm talking about the netlink because it's a natural source of streamed uevents, which is exactly what you want to give to a long-lived uevent handler such as mdev -i. I really have no idea why you're fixated on that fifo idea when all the pieces that you need already exist. A netlink listener forking a long-lived event handler and transmitting events to it via an anonymous pipe is the simplest design that will accomplish what you want. Pardon my bluntness, but I think you've been in write-only mode since the beginning of the discussion, and it is irritating. You are certainly very experienced, but you are not the only one who knows how Unix works; you are convinced we are not understanding your great plan, or that we want to prevent you from organizing your computers the way you want, or that you need to explain to us how fifos and super-servers work; none of that is true. This is the busybox mailing-list, we are not as clueless or malevolent as some people you may have had the displeasure of working with; and would you believe, some of us know how to design Unix software that does not need a power plant to run. Please take a look at my s6-uevent-listener/s6-uevent-spawner, or at Natanael's nldev/nldev-handler. The long-lived uevent handler idea is a *solved problem*. Take the code, busyboxify it if you want, make it into a single binary, whatever; all the tools you need are there. You have: - a short-lived uevent handler, registrable as a hotplug helper: mdev - a long-lived uevent handler: mdev -i (it's not there yet, but AIUI that's what you wanted to work on) - a netlink listener: s6-uevent-listener or nldev - a coldplug trigger: mdev -s - just in case someone would want that (and until mdev -i actually exists, we do want that), you even have long-lived programs suitable to be spawned by a netlink listener, that themselves spawn a helper such as mdev for every event: s6-uevent-spawner or nldev-handler. The advantage of this construct over simply registering mdev in /proc/sys/kernel/hotplug is that serializes events. It does not get any simpler, or more modular, than this set of tools. Your original plan was to: - write mdev -i: I think it's a good idea. - modify mdev -s to add more functionality than just triggering a coldplug: I don't think it's good design but I don't care as long as I can configure it out. Other people have also answered. The answers may not have been the ones you were looking for, but you wanted feedback, you got feedback. I'm not interested in providing 15 APIs to do the same thing. Users don't like the netlink ? Tough, if they want serialized uevents. What would you do if your kid wanted to drive a car but said he didn't like steering wheels, would you build him a car with a joystick ? I provided you with clear designs and working code. So did other people. (You said code is premature at this point. I'm sorry, but no, code is not premature when the problem is solved, and if you're not convinced, please simply study the code, which is extremely short.) Now it's all up to you. I would like to see a mdev -i, can you work on it ? If you prefer to keep beating around the bush and smoking crack about fifo superservers, it's fine too, but I'm just not interested. -- Laurent _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
