On 13.03.2015 11:51, Laurent Bercot wrote:
I think that adding hotplug helper management in a hotplug helper
needlessly complicates things.
Complicate? Yes!
Needless? I doubt!
Needless in your eyes? Needless in my eyes? Sure!
... but others may answer it different.
So why bother? With a modular system you can put things together in the
way you like.
It's easy enough to run the following in the init sequence:
1. start a netlink listener with a long-lived handler
2. coldplug stuff
3. register a hotplug helper
4. kill the netlink listener.
??? netlink in the phase of cold plug then switch to kernel helper
methode ... got a bit confused ... ok we talked about very small
systems, but doesn't seam to be the normal requirements, but
nevertheless possible with a modular system.
And your #3 is, where my inclusion of setting the hotplug helper in mdev
occurred (even if ony this one echo operation). Before #1, #2 or #3 is
able to send event messages to an handler, the named pipe (fifo) has to
be created. netlink start and cold plug may auto start, but if you do
that echo in the scripts, you need also to startup the fifo. On the
other side, adding that one echo line to mdev and let a command option
select the plug mechanism used, simplifies usage, as all mechanisms
involve the same setup steps (just change one parameter to select
method). So normal system startup will be:
#0 - initial creation of the device file system
#1 - run a single device management command, setting parameter
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)
Where each of the mentioned parts except the fifo startup can easily be
opted out on config, but otherwise add only some unused bytes in BB
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 be either (other combinations possible)
xdev -s = do old sys file scanning
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 is 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, then are the other requested actions taken.
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).
To avoid duplicating event handling between 3 and 4, both the
short-lived hotplug helper and the long-lived handler can take a
lock.
As an idea: When the parser holds a small table with the names from the
last N events (names? don't the kernel provide an event number? heard
something about this), for any new incoming event it can be checked if
the same message came in before, and then just ignored. Otherwise the
operation is done and the message placed in the least recently used
table slot (simple linked LRU list).
This is only an idea to add extra safety against duplicate event race
conditions. Can otherwise be left out when dropping that safety. My
suggestion: Implement it, but let it depend on a "hidden" config option
(not in config system, at start of source file). The default setting can
be discussed later.
read_conffile(...);
if( LRU_ENABLE )
{
setup_lru_table();
}
while( read_message(msg) )
{
if( !LRU_ENABLE || !message_in_lru(msg) )
{
do_device_operation(msg);
}
if( LRU_ENABLE )
{
update_lru_table(msg);
}
}
--
Harald
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
