Re: The Next Generation

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

On Fri, 2005-02-25 at 15:17 -0800, Greg KH wrote:
>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.

No, I didn't like it from the first day on. :)
We should remove that crap and emulate dev.d/ with a external helper,
which is optional. A simple rule like:
  HOTPLUG="/sbin/dev_d-execute"

should do it.

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

SuSE and Fedora will never support any system without udev again. The
people who don't like udev can switch off the node creation or still
stick with todays hotplug. There will never be a sane Next Hotplug
without event management like udevd is doing. That will never work
reliable, like it was with the old multiplexer.

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

They can stick with the old things, what's wrong with that? We can even
emulate the hotplug.d/ with your tiny multiplexer, by plugging it in
with a rule, the same way we can emulate dev.d/.

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

But we already handle hotplug.d/ with udev today. There is not much of a
difference. :)

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

All that is already there in udev/udevd. You just need to be able to
switch the node creation/removal off.

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

And again, I really don't know what we can do _with_ udev for people who
don't want it. There will never be a Next Generation without sequence
reordering and sysfs waiting.

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