Re: The Next Generation

[Greg KH <greg@kroah.com>]

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