From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Fri, 25 Feb 2005 23:17:14 +0000 Subject: Re: The Next Generation Message-Id: <20050225231714.GA28735@kroah.com> 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 Thu, Feb 17, 2005 at 08:09:41PM +0100, 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. I agree. > 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. Ok. > The directory device match logic, even the more advanced one proposed > yesterday, will never meet our requirements to limit system usage > at event time. We should expect a ever growing number of hotplug events > and need to be prepared to execute only the stuff which is really needed > for a specific device. Ok. > 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. No, we can't break backward compatiblity like that. We need to always support the /etc/hotplug.d/ way, as we've already told too many people they can rely on that always working. We _can_ change the /etc/hotplug/ stuff, and I'm all for throwing the mass of shell scripts there away. I don't think there are very many remaining external programs that still rely on putting themselves in that directory. And /etc/dev.d/ is also a good thing to have. > I propose to make the udev architecture _the_ generic hotplug handler. As much as I would _love_ to do this, we can't. Too many people would reject it. We can't force udev onto everyone, no matter how many times I tell them it's the right thing to do. Now we _can_ build hotplug-ng out of udev pieces and parts, that I don't have a problem with. And, if udev is running on a box, have it handle the hotplug functionality is also an acceptable thing (as long as nothing external to udev has to change, like the scripts in /etc/hotplug.d/). But we can't mandate that udev must be used, sorry. > We use the same rules which we are using today to compose a name for a > specific device. We just need something like a POSTPROCESS="/sbin/some-program" > key for our rules which adds a program to a list of programs to be executed > after the device node is created. Now I don't have a problem with this, but that's a udev specific thing, not a hotplug handler thing. > 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. And sure, it would give us the efficiency one can > expect from a "next generation" thing. :) The main hotplug handling shouldn't be rule based, it should be driven off of the subsystem and environment variables passed to it, like today. What I want to see the hotplug-ng stuff handle is this: - not being a shell script, we need tiny and fast for both huge boxes, and tiny embedded systems. - be a drop in replacement for the current /sbin/hotplug multiplexer. - be a drop in replacement (through other helper programs) to the existing linux-hotplug module loading scripts. - Extend the current hotplug functionality with a finer grained way of executing other programs (like going off of the DEVPATH or bus specific values, like was proposed on the linux-hotplug-devel list.) - Possibly handle the wait-for-sysfs and reording logic that udev currently does. While not as far-reaching as your proposal, I think it is a good step forward, as it addresses a number of issues that people have today with the current hotplug setup, while not forcing anyone to convert to using udev. thanks, greg k-h ------------------------------------------------------- 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