Re: [RFC] /sbin/hotplug multiplexor - take 2

[David Brownell <david-b@pacbell.net>]

Greg KH wrote:
 > On Tue, Apr 15, 2003 at 12:19:51PM -0700, David Brownell wrote:
 >
 >>I'd think better about this problem if I had a handful of
 >>examples showing why category-specific or event-specific
 >>dispatch wouldn't be preferable.
 >
 >
 > udev is such an example.  I want it to run for every hotplug event.  To
 > do that with the current scripts, I have to either modify the current
 > scripts to always call it (not a big deal, I have CVS access :) or add a
 > handler for every type of device, and every type of those devices.

I'd go for the "always" call it (if /sys/$DEVPATH/dev exists and
udev is enabled).  That's category-specific ... but the category is
determined by looking at system state, not the event type ($1).


 > devlabel is also another type of example.  The author of that had to
 > persuade us to modify the scripts in order to get support for his
 > program.  I don't want to be a gating function, with this simple
 > proposal, he could just dump the devlabel script into the /etc/hotplug.d
 > directory in the proper place and everything would just work.

There's always some kind of gate!  (And shouldn't "devlabel"
just morph into the "namedev" thing that "udev" wants, so it'd
go away soonish"?)


I guess there's a different question I see lurking, and that's
how "Hotplug NG" starts to develop -- how many things should
change, and why.  Multiplexing is only one thing to consider,
likely more things should be on the table.  Including how much
to tie to 2.5 capabilities like the new modprobe aliasing, and
how to get from here to there.


 > I've also been hearing from lots of other people (interestingly, not
 > publicly, I guess they like to stay hidden for some reason) that also
 > hook the hotplug scripts.  They have usually been either recommending
 > that their users patch the current script, or just replace the current
 > ones all together (thereby loosing the module load functionality) in
 > order to support their devices.  This proposal would also help them, and
 > their users.

I like the direction of allowing easier extensibility.
But I do worry about making it too easy to create chaos.

Maybe I worry too much -- the bad mutations should just
die out, rather than becoming a cancer that kills.

- Dave



 > thanks,
 >
 > greg k-h
 >







-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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