Re: The Next Generation

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

On Sunday 27 February 2005 3:34 pm, Kay Sievers wrote:
> On Sun, 2005-02-27 at 12:13 -0800, David Brownell wrote:
> >> 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. :(

CF is SFF-PCMCIA, yes.  Maybe PCMCIA will soon (finally!) get rid of
cardmgr and just be able to rely on the hotplug infrastructure, like
its CardBus sibling!  (Clearly there's no inherent need for a cardmgr,
since CardBus/PCI never needed one.  There are interesting patches in
the latest MM tree code...)


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

Well 30% of three minutes is still about 50 seconds too long, but
that's certainly going in the correct direction!  :)

A better target would be about 0.5% of current, not 30% of current.


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

I've seen the mail and patches flying around, certainly.  But the short
summary of all that is that 2.6.12 kernels (with matching udev) will be
better, but may still not quite be ready for the cutover you suggest.
Even for totally bleeding edge kamikaze systems ... and even if they
were, that means that it'd only be then (when, June?) that systems
using new infrastructure could start working that way.  Deploying that
stuff in robust systems would take longer.


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

Next time I build a sytem, I'll keep an eye out for that.  Some of
that is probably that the OpenEmbedded stuff isn't smart about some
things it does.  (It took more than three extra minutes until I made
some simple changes to the udev setup...)


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

That might be interesting, but the early boot stuff is still not wholly
cooked either.  RAM is more scarce than on desktops, and it'd be nice
if the static device list could stay on a JFFS2 /dev and have only the
dynamically hotplugged devices (USB, CF, MMC, etc) be managed in RAMfs
by udev.  That sort of issue isn't entirely a udev thing, but design
choices in udev can complicate things there too.
 
- 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