From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Wed, 02 Mar 2005 07:13:28 +0000 Subject: Re: The Next Generation Message-Id: <200503012313.28303.david-b@pacbell.net> List-Id: References: <20050217190941.GA1561@vrfy.org> In-Reply-To: <20050217190941.GA1561@vrfy.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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_id396&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