Re: The Next Generation

[David Brownell <david-b@pacbell.net>]

On Thursday 17 February 2005 11:09 am, Kay Sievers wrote:
> After the recent discussion about a possible new hotplug handler layout
> I see the need for a completely different approach. We need to clean
> up the current mess, reduce all the silly options and give a sane
> environment without all the hacks and shortcomings.

That is, a third generation of how to manage the userspace events:

 - /etc/hotplug scripts, 2.4.0-test10 and later.  These introduced
   the newish notion that Linux should should primarily respond to
   configuration events on-the-fly, delegating hardware-to-driver
   policy to the kernel modules and other setup policies to various
   userspace tools.  This was essential before USB or CardBus/PCI
   could become widely used.

 - /etc/hotplug.d, phasing in during 2.6 along with enhancements to
   use the driver model more effectively (and udev).  More bus types;
   and sysfs meant the hotplug events didn't need to carry as much
   data (though their handlers might need to wait longer).

 - Next Generation (TBD)

Somehow I don't think this can stop with one "next generation"!  The
Linux developer community is still evolving how it wants to see
different systems reconfigure.  Today's "Next Generation" will be
tomorrow's silly limitation/hack ... to be replaced or evolved.


> A real "next generation" can only be sane with managed hotplug events,
> which prevents races with sysfs timing and cares about order and
> dependencies between the events.

The current generation is managed too ... you just want to see it
managed _differently_ ... :)

Though it's also worth (IMO) distinguishing various different aspects
of management.  I usually draw the lines as:  what the events are
(contents etc); how the kernel delivers them (e.g. does it deliver
in-order, through uevents or /sbin/hotplug, etc); and how they get
dispatched through userland.  That latter can involve multiple
frameworks, begging questions about how they interoperate.


> For that reason, we should get rid of all the just too simple
> brute-force logic in /etc/hotplug/*, /etc/hotplug.d/ and /etc/dev.d/, which
> requires scripts to check if they are called for the right device.

That'd be /etc/hotplug/$BUS/$MODULE if I understand what you mean,
but yes I certainly support being able to decommission /etc/hotplug.
Not as a "change everything, flag day!" event though.

The original logic for expecting those scripts to check that stuff
was that there was no better option.  The driver model started to
give us such options, especially once it let the hotplug events
see (albeit indirectly through sysfs) the /dev node associated with
a given physical device ... and decouple the "modprobe driver"
event from the "driver activates /dev node" event.

Remember that it amazed enough people at the time just to see
Linux systems automatically load the driver module ... it took
most developers a while to realize some of the missing steps!


> I propose to make the udev architecture _the_ generic hotplug handler.

Speaking as someone who's been content to let other folk drive the
evolution of hotplug for a while, I think it's not yet ready; but
I'm not averse to moving away from shell scripts as the main glue.
For the first generation, shell scripts were essential.

Why do I say it's not yet ready?  One example:  I recently configured
an OpenEmbedded build to use udev (instead of devfs) and that grew
the boot time from about 5 seconds to about 3 minutes.  (With a very
generic kernel, and not many devices ...) Considering that the target
is closer to one second, "udev" clearly lost big.  And I've seen
corresponding udev thrashing from my SuSE 9.2 laptop; cutting battery
lifetime by 15% when I plug in a CF card (AND am lucky enough to notice
and find a way to kill the endless loop) is not good.  


> This way we would get a nice, clean and understandable rule based event handling
> with a single source of policy, and not the current mess with confusing directories
> spreaded all over the system.

Like it or not, dynamically configuring a complex system must
involve multiple sources of (sometimes conflicting) policy,
and modular design that probably means multiple directories.

And _evolving_ a working system means that probably a few
messy vestiges will be left around ... 


> And sure, it would give us the efficiency one can 
> expect from a "next generation" thing. :)

Sounds like apple pie -- tasty!  Or "democracy", wherein the
devil is in the details (like who decides who gets to vote, and
for who/what, and whether their wishes are then ignored).

- Dave



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel