/sbin/hotplug multiplexor - take 2
Ok, based on the comments so far, how about this proposed version of /sbin/hotplug to provide a multiplexor?
thanks,
greg k-h
----------
#!/bin/sh
DIR="/etc/hotplug.d"
for I in "${DIR}/$1/"* "${DIR}/"all/* ; do
test -x $I && $I $1 ;
done
exit 1
----------
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · Greg KH
Ok, based on the comments so far, how about this proposed version of
/sbin/hotplugto provide a multiplexor?
It'd be a reduction in functionality. I could no longer just type "/sbin/hotplug" to see what agents disabled or missing ... or notice that since hotplugging was on, the problem had to be RH9 storing /bin/true into /proc/sys/kernel/hotplug again! :P
If the idea is just to loosen today's "one agent per event" rule (I've had that idea too), then wouldn't it be simpler to just (a1) pay an extra process context, not using "exec" to run /etc/hotplug/$1.agent, and when it returns (a2) THEN try other programs? Or even (b) just modify appropriate agent scripts to do so, instead of /sbin/hotplug?
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.
- Dave
Quoted 10 lines
----------
#!/bin/sh
DIR="/etc/hotplug.d"for I in "${DIR}/$1/"* "${DIR}/"all/* ; do
test -x $I && $I $1 ;done
exit 1
----------
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines
From: Greg KH [mailto:[email protected]]
...
for I in "${DIR}/$1/"* "${DIR}/"all/* ; do
test -x $I && $I $1 ;
test -x "$I" && "$I" "$1"
Just in case?
Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault)
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · David Brownell
Quoted 2 lines · Greg KH
Ok, based on the comments so far, how about this proposed version of
/sbin/hotplugto provide a multiplexor?It'd be a reduction in functionality. I could no longer just type "
/sbin/hotplug" to see what agents disabled or missing ... or notice that since hotplugging was on, the problem had to be RH9 storing/bin/trueinto/proc/sys/kernel/hotplugagain! :P
Well you can still do that, the current scripts will get run that way too.
Quoted 10 lines
If the idea is just to loosen today's "one agent per event" rule (I've had that idea too), then wouldn't it be simpler to just (a1) pay an extra process context, not using "exec" to run
/etc/hotplug/$1.agent, and when it returns (a2) THEN try other programs? Or even (b) just modify appropriate agent scripts to do so, instead of/sbin/hotplug?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.
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.
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.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · Greg KH
Ok, based on the comments so far, how about this proposed version of
/sbin/hotplugto provide a multiplexor?
I think it would be good to launch only the files ending by a special extension to avoid running backup files. Something like that:
#!/bin/sh
DIR="/etc/hotplug.d"
for I in "${DIR}/$1/"*.hotplug "${DIR}/"all/*.hotplug ; do
test -x $I && $I $1 ;
done
Signature · 11 lines
Fred - May the source be with you ------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · Frederic Lepied
Quoted 2 lines · Greg KH
Ok, based on the comments so far, how about this proposed version of
/sbin/hotplugto provide a multiplexor?I think it would be good to launch only the files ending by a special extension to avoid running backup files. Something like that:
Ah, good idea, will do.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines · Inaky
Quoted 7 lines
From: Greg KH [mailto:[email protected]]
...
for I in "${DIR}/$1/"* "${DIR}/"all/* ; do
test -x $I && $I $1 ;test -x "$I" && "$I" "$1"
Just in case?
Good idea, I've changed it.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines · Greg KH
Quoted 3 lines · David Brownell
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).
Quoted 5 lines
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.ddirectory 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.
Quoted 7 lines
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
Quoted 4 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines · Greg KH
Quoted 3 lines · David Brownell
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).
Quoted 5 lines
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.ddirectory 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.
Quoted 7 lines
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
Quoted 4 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel