From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Sun, 27 Feb 2005 20:13:18 +0000 Subject: Re: The Next Generation Message-Id: <200502271213.19133.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 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_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