RFD: Rework/extending functionality of mdev

[Natanael Copa]

On Thu, 12 Mar 2015 17:26:38 +0000
Isaac Dunham <ibid.ag at gmail.com> 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