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
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
