On Thu, 12 Mar 2015 17:26:38 +0000 Isaac Dunham <[email protected]> wrote:
> On Thu, Mar 12, 2015 at 04:04:41PM +0100, Harald Becker wrote: > No, you misunderstand. Read my proposal below and tell me why this won't > do what you're after, OTHER than "the way mdev works now is broken/wrong", > since that *isn't* universally accepted. > > As you stipulated about your design, applet and option names can be changed > easily; but when I say "new applet", I mean to indicate that this should > be separate from mdev. > > * mdev (no options) > ~ as it works now (ie, hotplugger that parses mdev.conf itself) > * mdev -s (scan sysfs) > ~ as it works now, or could feed the mdev parser yes. > * mdev -i/-p (read events from stdin) > mdev parser, accepting a stream roughly equivalent to a series of > uevent files with a separator following each event[1]. > To make it read from a named pipe/fifo, the tool that starts it > could use dup2(). Yes. this is an option. I am not convinced it is the best solution though. I think that the changes in mdev might be more intrusive than mdev maintainer feel comfortable. Still I don't have any better ideas. While solving this, I would also like to find a way to load the MODALIAS without forking. One option is to add modprobe -i which reads modaliases from stdin with a timeout. Maybe that is a lower hanging fruit than mdev -i? > * new applet: nld > Netlink daemon that feeds mdev parser. I have implemented a proof-of-concept for this in case someone want experiment with mdev -i: http://git.alpinelinux.org/cgit/ncopa/nldev/tree/nldev.c I am not convinced that this should be implemented as busybox applet. It would be nice if it was though. > * new applet: fifohp > Your hotplug helper, fifo watch daemon that spawns a parser, and > hotplug setup tool. > > I had actually thought that it might work at least as well if, > rather than starting a daemon at init, the fifo hotplugger checks if > there's a fifo and *becomes* the fifo watch daemon if needed. > > Also, I was thinking in terms of writing to a pipe because that lets > us make sure events get delivered in full (ie, what happens if mdev > dies halfway through reading an event?) Yes. Partially written/read events needs to be handled properly, as Laurent pointed out too. > This way, > + mdev is the only applet parsing mdev.conf; > + all approaches to running mdev are possible; > + it's easy to switch from mdev to the new hotplugger, > while still having mdev available if the new hotplugger breaks; > + mdev is only responsible for tasks that involve parsing mdev.conf. > > And people who want the change don't have to do more than your > proposal would require. This is the direction I want go, yes. > [1] The format proposed by Laurent uses \0 as an "line" terminator; > I think it might be better to use something that's more readily > generated by standard scripting tools from uevent files, which would > make it possible to use cat or env to feed the mdev parser. I liked the \0 as event terminator. Its simple. -nc _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
