RFD: Rework/extending functionality of mdev

[Harald Becker]

Hi,

my original intention was to replace mdev with an updated version,
but as there where several complains which told they like to continue 
using the the old suffering mdev, I'm thinking about an alternative.

... but the essential argument came from James, fail save operation.

In my last summary I used the name xdev, just as a substitution to 
distinguish to current mdev. I don't think the name xdev would be a good 
choice to stay with, neither is nldev, as my approach allows to include 
/ used different mechanisms, ...

... so what would be the best choice for a name of this updated 
implementation of the device system management command?

With a different name, we can just leave the mdev code as is, and in a 
new applet with different code (no code sharing except usual libbb). 
Then you can opt in whichever version you like, or even both and chose 
during runtime which one to use.

... but if now someone complains about the big code size overhead when 
two device managers get included without code sharing, I send him an: 
kill -s 9 -1

... and I won't later to change the name of the new xdev implementation 
to the name mdev, because someone complains and want to use newer 
version but stay at the name mdev.


So call the command xdev for now, to distinguish to current mdev operation:

xdev -i
   - do the configured initial setup stuff for the device file system
     (this is optional, but I like the one-shot startup idea)

xdev -f
   - starts up the fifo manager, if none running
     (manual use is special purpose only)

xdev -k
   - disable hotplug handler, kill possibly running netlink daemon
     (for internal and special purpose usage)
     kill is not perfect yet, race condition when switching mechanisms
     (needs more thinking)

xdev -p   (changed the parameter due to criticism)
   - select the kernel hotplug handler mechanism
     (auto include -f and -k)

xdev -n
   - select the netlink mechanism and start daemon
     (auto include -f and -k)

xdev -c
   - do the cold plug initiation (triggering uevents)
     (also auto include -f)

xdev -s
   - do the cold plug as "mdev -s" does
     (also auto include -f)

xdev (no parameter)
   - can be used as kernel hotplug helper

xdev netlink
   - the netlink reader daemon
     (this is for internal use)

xdev parser
   - the mdev.conf parser / device operation process
     (this is for internal use)

Command parsing will be stupid, if not an option, the first character is 
checked, so "xdev pumuckl" is same as "xdev parser".

Where each of the mentioned parts except the fifo startup can easily be 
opted out on config, but otherwise add waste only some bytes in then 
binary. The fifo manager (named pipe supervisor) daemon itself is not 
included in this list, as a general fifosvd as separate applet seams to 
be the better place (just used internal by -f).

current mdev -s may get either (other combinations possible)

   xdev -s    = do sys file scanning as "mdev -s", but use new back end
   xdev -pc   = kernel hotplug mechanism, trigger the cold plug
                (uses xdev as hotplug handler)
   xdev -nc   = netlink mechanism, trigger the cold plug
                (starts xdev netlink reader daemon)

The only other change in the init scripts shall be to remove the old 
setting of mdev as hotplug helper in the kernel completely (done 
implicitly by -p).

All those may be combined with -i, then at first the configured setup 
operations are performed, thereafter the other requested actions.

That does *not mean* xdev -i does do any binary encoded setup stuff. It 
shall read the config file (suggestion is first try /etc/xdev-init.conf, 
then fallback to /etc/xdev.conf when former not exist) and invoke 
required operations for the configured setup lines. The setup lines are 
only used in xdev -i and otherwise ignored by xdev parser (like comments).


... more brain storming:

Just for those who may need such a feature: If you start the fifo 
supervisor manually, you can arrange to startup a different back end 
parser. This may be used to send all device event messages to a file:

#!/bin/busybox sh
tee -a /dev/.xdev-log | exec xdev parser

When this wrapper is used as back end, it will catch and append a copy 
of each event message to /dev/.xdev-log, which could itself be a named 
pipe to put messages in a file and watch file size to rotate files when 
required.

... but thinking of adding an "xdev -l[LOG_FILE]", which overwrite "-f" 
and setup the fifo supervisor to do the logic of the above wrapper, but 
without invoking an extra shell.

Some neat trick: xdev -l/dev/tty9 -pc
   start fifo supervisor
   set xdev as hotplug helper
   trigger the cold plug events
   beside normal parsing a copy of all event messages is written to tty

And again: This is not for normal usage, only for debugging purposes and 
those interested in lurking at their device messages.


... as a may be:

xdev -e[FAILURE_SCRIPT]
   spawn the failure script, when an operation has serious problems
     FAILURE_SCRIPT PROG_NAME EXIT_CODE_OR_SIGNAL [FAILURE_COUNT]
   (may be added to -f, -n, -c, -s, and netlink)

xdev -f[FIFO_NAME] [PROG [ARGS]]
   extended form of the fifo manager startup
   the defaults are: xdev -f/dev/.xdev-pipe /bin/busybox xdev parser