Re: The Next Generation

[Kay Sievers <kay.sievers@vrfy.org>]

On Sun, 2005-02-27 at 12:13 -0800, David Brownell wrote:
>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.

Sure, it was the -ng in Greg's new hotplug package that lead to that
subject. :)

>> 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.

That does mean what?

>> 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.

Oh, we do not want break anything here. Every current stuff will be
plugged in by default as long as it is needed. And we need rules to
handle that and not directories. There are too many options/values to
match at event time to get a sane directory layout, I think.

>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!

Yeah, that's a good point. People on the bleeding edge tend to forget
all that.

>> 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.  

It is a pcmcia device, right? The kernel does not work well here and it
is not udev's fault. We talked to the kernel guys, cause with HAL we had
the same trouble but got not very friendly responses and gave up on
that. :(

But we did a lot of things over the last weeks to address the other
problems. We have a new libsysfs now, which is much much faster, we have
the "bus" link and don't need to look at all the files in sysfs to get
the bus value the device is on and we have the driver and physical
device in the environment and don't need to wait for something that will
never show up in sysfs.
We will get rules for the dev.d/ scripts which cuts the running time of
udevstart to ~30% on my box.
And I sent a patch to change to the kobject core to be able to send the
hotplug events after the default files in sysfs are created which will
be much nicer than todays stat() looping udev processes.

Let me know of any concrete problems with the newer kernel+udev versions
you see on any of your boxes and I will see what I can do.

It may even be an option for the embedded stuff to run a very tiny udev
without a dependency on sysfs, cause all the basic informations (bus,
driver, physical device, major/minor) are available with the hotplug
environment now.

>> 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.

Hmm, we just talk about handling hotplug events. What do you have in
mind here? If you see any specific problem, let me know.

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

Sure, that's the way how every complex system is, right?

>> 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).

Yes, but we still need to move to see what we need to change. :)

Thanks,
Kay



-------------------------------------------------------
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