On Thu, Mar 12, 2015 at 04:04:41PM +0100, Harald Becker wrote: > Hi Isaac ! > > On 12.03.2015 02:05, Isaac Dunham wrote: > >>>I just don't think you're quite thinking through exactly what this means. > >>In which sense? Let me know, what I got wrong. I'm a human, making mistakes, > >>not a perfect machine. > > > >It seems like you want to force everyone who uses mdev to use a multi-part > >setup. > > Whops, you got that definitely wrong! Who told you, I want to force you to > use a different setup. My clear intention, was adding some extra > flexibility, without breaking existing usage. > > ... but criticism arose, which poked for more clarity. Only due to this and > the wish to allow fitting as much preferences of people as possible, there > might result a slight change: One extra operation may be required (when not > not combined / hidden in the mdev system for clarity). At the location you > setup the hotplug handler or do "mdev -s" you either need a slight change of > the command parameters or need to insert a single extra command (details on > this have not been discussed yet). But that's it. > > Are you really concerned about inserting a single extra line in your startup > scripts or having a modification to one of those lines? That way you would > block any innovation, *and* the needs of other people.
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 * 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(). * new applet: nld Netlink daemon that feeds mdev parser. * 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?) 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. [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. Thanks, Isaac Dunham _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
