/sbin/hotplug multiplexor
Hi all,
With the advent of a lot of people wanting to use /sbin/hotplug to add their own different types of functions, I want to propose the following replacement for the current /sbin/hotplug:
-----
#!/bin/sh
DIR="/etc/hotplug.d"
for I in "${DIR}/"* ; do
$I $1 &
done
exit 1
-----
Then all scripts/programs/whatever that wants to get called when /sbin/hotplug goes off can add themselves to the /etc/hotplug.d directory.
This should help solve the recent devlabel issue with the current hotplug scripts, and allow things like udev to also watch all hotplug actions.
Any objections or comments? If not, I'll make the changes in the linux-hotplug project and release a new version based on this.
Thanks to Martin Schwenke for giving me this idea (even if he doesn't realize it :)
Note, this is only for the "big" hotplug versions that live on everyone's disk. I'm still advocating something small like a combination of udev and dietHotplug for the initramfs image.
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 3 lines
Any objections or comments? If not, I'll make the changes in the linux-hotplug project and release a new version based on this.
Yes, consider what this does if you connect to a FibreChannel grid. You are pushing system load by at least an order of magnitude.
Regards
Oliver
-------------------------------------------------------
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 6 lines · Oliver Neukum
Quoted 3 lines
Any objections or comments? If not, I'll make the changes in the linux-hotplug project and release a new version based on this.
Yes, consider what this does if you connect to a FibreChannel grid. You are pushing system load by at least an order of magnitude.
When you add a FibreChannel grid, the devices are discovered in sequential order, with SCSI IO happening between each device discovered. In talking to the SCSI people, that should be about 30ms per device found at the quickest. So there's no /sbin/hotplug process storm :)
And even if there is, we have to be able to handle such a load under normal situations anyway :)
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
Am Montag, 14. April 2003 21:54 schrieb Greg KH:
Quoted 7 lines · Oliver Neukum
Quoted 5 lines
Quoted 2 lines
Any objections or comments? If not, I'll make the changes in the linux-hotplug project and release a new version based on this.
Yes, consider what this does if you connect to a FibreChannel grid. You are pushing system load by at least an order of magnitude.
Quoted 7 lines
When you add a FibreChannel grid, the devices are discovered in sequential order, with SCSI IO happening between each device discovered. In talking to the SCSI people, that should be about 30ms per device found at the quickest. So there's no
/sbin/hotplugprocess storm :)And even if there is, we have to be able to handle such a load under normal situations anyway :)
Well, plugging them in is one case. But what is plugged in, will eventually be unplugged as well. That will not require probing.
Now let's be conservative and assume 16KB unswappable memory per task. Now we take the famous 4000 disk case. 64MB. A lot but probably not deadly. But multiply this by 15 and the machine is absolutely dead.
Regards
Oliver
-------------------------------------------------------
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 16 lines · Oliver Neukum
Am Montag, 14. April 2003 21:54 schrieb Greg KH:
Quoted 7 lines · Oliver Neukum
Quoted 5 lines
Quoted 2 lines
Any objections or comments? If not, I'll make the changes in the linux-hotplug project and release a new version based on this.
Yes, consider what this does if you connect to a FibreChannel grid. You are pushing system load by at least an order of magnitude.
Quoted 7 lines
When you add a FibreChannel grid, the devices are discovered in sequential order, with SCSI IO happening between each device discovered. In talking to the SCSI people, that should be about 30ms per device found at the quickest. So there's no
/sbin/hotplugprocess storm :)And even if there is, we have to be able to handle such a load under normal situations anyway :)
Quoted 7 lines
Well, plugging them in is one case. But what is plugged in, will eventually be unplugged as well. That will not require probing.
Now let's be conservative and assume 16KB unswappable memory per task. Now we take the famous 4000 disk case. 64MB. A lot but probably not deadly. But multiply this by 15 and the machine is absolutely dead.
Ok, then the "Enterprise Edition" of the distros that expect to handle 4000 disks will have to add the following patch to their version of the hotplug package.
In the meantime, the other 99% of current Linux users will exist just fine :)
greg k-h
hotplug renamed from hotplug.orig +1 -1
@@ -2,7 +2,7 @@ DIR="/etc/hotplug.d" for I in "${DIR}/"* ; do - $I $1 & + $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 6 lines
Quoted 5 lines
Now let's be conservative and assume 16KB unswappable memory per task. Now we take the famous 4000 disk case. 64MB. A lot but probably not deadly. But multiply this by 15 and the machine is absolutely dead.
Quoted 6 lines
Ok, then the "Enterprise Edition" of the distros that expect to handle 4000 disks will have to add the following patch to their version of the hotplug package.
In the meantime, the other 99% of current Linux users will exist just fine :)
Well, for a little elegance you might introduce subdirectories for each type of hotplug event and use only them.
Regards
Oliver
-------------------------------------------------------
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 9 lines · Oliver Neukum
Quoted 9 lines
Quoted 4 lines
Now let's be conservative and assume 16KB unswappable memory per task. Now we take the famous 4000 disk case. 64MB. A lot but probably not deadly. But multiply this by 15 and the machine is absolutely dead.
Ok, then the "Enterprise Edition" of the distros that expect to handle 4000 disks will have to add the following patch to their version of the hotplug package.
Quoted 7 lines
Quoted 2 lines
In the meantime, the other 99% of current Linux users will exist just fine :)
Well, for a little elegance you might introduce subdirectories for each type of hotplug event and use only them.
Personally, this is one reason why I'd much rather see a daemon-based model where each interested daemon can "subscribe" to the messages it is interested in. It's very possible (and likely, i.e. udev) that the steps involved for the daemon to respond to the hotplug event are so lightweight that creating a subprocess to handle them would be very wasteful.
Also, this lends itself to multiple levels of messaging: say, for example, userspace partitioning. How would the proposed scheme manage to invoke the userspace partition reading _after_ udev has done its job? If udev itself generated a message into the queue after the device node had been created, the partitioning code could listen for that instead of the native hotplug event.
-------------------------------------------------------
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 10 lines · Oliver Neukum
Quoted 10 lines
Quoted 5 lines
Now let's be conservative and assume 16KB unswappable memory per task. Now we take the famous 4000 disk case. 64MB. A lot but probably not deadly. But multiply this by 15 and the machine is absolutely dead.
Ok, then the "Enterprise Edition" of the distros that expect to handle 4000 disks will have to add the following patch to their version of the hotplug package.
Quoted 5 lines
Quoted 2 lines
In the meantime, the other 99% of current Linux users will exist just fine :)
Well, for a little elegance you might introduce subdirectories for each type of hotplug event and use only them.
No, that's for the individual scripts/programs to decide. For example, that's what the current hotplug scripts do, but that's not at all what the udev program wants to 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 6 lines · Kevin P. Fleming
Personally, this is one reason why I'd much rather see a daemon-based model where each interested daemon can "subscribe" to the messages it is interested in. It's very possible (and likely, i.e. udev) that the steps involved for the daemon to respond to the hotplug event are so lightweight that creating a subprocess to handle them would be very wasteful.
One of the hotplug programs will create a D-BUS message that anyone can subscribe to. But I don't want to add that to one of the existing hotplug programs, as it's a separate task. That's one reason for the proposed change.
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 7 lines
Quoted 3 lines
Well, for a little elegance you might introduce subdirectories for each type of hotplug event and use only them.
No, that's for the individual
scripts/programsto decide. For example, that's what the current hotplug scripts do, but that's not at all what the udev program wants to do.
So have them put a symlink into each subdirectory. This is the way it's done for init since times immemorial.
Regards
Oliver
-------------------------------------------------------
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 5 lines · Kevin P. Fleming
Personally, this is one reason why I'd much rather see a daemon-based model where each interested daemon can "subscribe" to the messages it is interested in. It's very possible (and likely, i.e. udev) that the steps involved for the daemon to respond to the hotplug event are so lightweight that creating a subprocess to handle them would be very wasteful.
This screams for d-bus.
I spent the weekend reading about it and I spoke with some of the d-bus hackers.
It is really neat and certainly something we should look into.
See http://www.freedesktop.org/software/dbus/
Robert Love
-------------------------------------------------------
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 10 lines · Oliver Neukum
Quoted 7 lines
Quoted 3 lines
Well, for a little elegance you might introduce subdirectories for each type of hotplug event and use only them.
No, that's for the individual
scripts/programsto decide. For example, that's what the current hotplug scripts do, but that's not at all what the udev program wants to do.So have them put a symlink into each subdirectory. This is the way it's done for init since times immemorial.
But the number of different "types" keeps growing. For some programs (like udev) they really don't care about the type, and if you add a new type, it still works just fine. Other programs do care about the type, so they can look at it and make a judgement based on 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
Am Montag, 14. April 2003 23:52 schrieb Greg KH:
Quoted 8 lines · Oliver Neukum
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Well, for a little elegance you might introduce subdirectories for each type of hotplug event and use only them.
No, that's for the individual
scripts/programsto decide. For example, that's what the current hotplug scripts do, but that's not at all what the udev program wants to do.
Quoted 7 lines
Quoted 2 lines
So have them put a symlink into each subdirectory. This is the way it's done for init since times immemorial.
But the number of different "types" keeps growing. For some programs (like udev) they really don't care about the type, and if you add a new type, it still works just fine. Other programs do care about the type, so they can look at it and make a judgement based on it.
How can that be? What kind of thing should care about both device addition and routing changes in the same way?
Not needlessly exposing scripts to event types they are not written to handle is an advantage.
Regards
Oliver
-------------------------------------------------------
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 · Arnd Bergmann
Quoted 2 lines · Oliver Neukum
Well, for a little elegance you might introduce subdirectories for each type of hotplug event and use only them.
I was just about to propose the same. Please use subdirs or namespaced files like in:
for I in "${DIR}/$1".* "${DIR}/"default.* ; do
test -x $I && $I $1done
Hm, default looks good, but why would it have a .*? How about:
for I in "${DIR}/$1/"* "${DIR}/"default/* ; do
That way the programs that really care about only one subsystem can be easily added, while everyone else can drop into the default directory (which odds are, everyone will want to be in...)
Sound ok?
Quoted 8 lines
Note that a single event can not only cause one hotplug event for many devices but also _multiple_ events for every device. E.g. enabling a dasd devices will cause hotplug to be called for the local subchannel devices as well as the actual (remote) disk. Maybe someone adds hotplug calls for partitions and logical volumes.
Since dasds are usually not larger than 2GB, you are quite likely to enable many at the same time. Imagine you get 500 disks * 4 events * 10 agents in response to a single user command...
Damm, you s390 people, always showing everyone else up :)
Ok, I'll take the '&' out for now, and serialize things within a single hotplug call.
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 12 lines · Oliver Neukum
Am Montag, 14. April 2003 23:52 schrieb Greg KH:
Quoted 11 lines · Oliver Neukum
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
Well, for a little elegance you might introduce subdirectories for each type of hotplug event and use only them.
No, that's for the individual
scripts/programsto decide. For example, that's what the current hotplug scripts do, but that's not at all what the udev program wants to do.So have them put a symlink into each subdirectory. This is the way it's done for init since times immemorial.
Quoted 7 lines
Quoted 4 lines
But the number of different "types" keeps growing. For some programs (like udev) they really don't care about the type, and if you add a new type, it still works just fine. Other programs do care about the type, so they can look at it and make a judgement based on it.
How can that be? What kind of thing should care about both device addition and routing changes in the same way?
No, udev doesn't care about routing changes. But there isn't enough hardcoded logic in it to care about the different subsystems, so it wants to figure out that it shouldn't care about an event all on its own.
Quoted 2 lines
Not needlessly exposing scripts to event types they are not written to handle is an advantage.
Ok, I like Arnd's proposal of a "default" directory. Maybe I should change that to "all" as no one better create a subsystem or driver class in the kernel called "all" :)
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 6 lines · Kevin P. Fleming
Quoted 5 lines
Personally, this is one reason why I'd much rather see a daemon-based model where each interested daemon can "subscribe" to the messages it is interested in. It's very possible (and likely, i.e. udev) that the steps involved for the daemon to respond to the hotplug event are so lightweight that creating a subprocess to handle them would be very wasteful.
Historically, one of the motivations for the /sbin/hotplug approach was to avoid the costs of running Yet Another Daemon that's idle almost all the time ... and all it'd do when it learns about a new device is fork an easily-customized shell script, which normally loads driver modules and runs device setup scripts. (Modprobe does per-driver scripts, which are no good for per-device actions, and needs a config file.)
Cheaper all around to have the kernel do that; plus, it had information that was not otherwise available to daemons. Much easier to adopt and evolve shell scripts, too.
That is, the design center was for medium-weight events that always involve starting new processes, and which moreover tend not to run often. How often do you connect a new USB or PCI device? If it takes a full second to react, that's OK; and Linux is usually faster than that. (Windows isn't! :)
I'd certainly agree that some hotplug agents need to be talking with daemons. But I've always thought of them as being application-specific ... tell the print server about a new printer, for example. And what you need to tell that server seems unlikely to be what you'd tell something that's sampling your collection of video or audio streams.
Quoted 1 line · Robert Love
Looks interesting.
- Dave
-------------------------------------------------------
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 · [email protected] said:
How often do you connect a new USB or PCI device? If it takes a full second to react, that's OK; and Linux is usually faster than that.
When I was running on a 66MHz system w/ 128Meg RAM, it took on the order of 30 seconds to get around to invoking fxload. The initial execute of /sbin/hotplug may be quick, but that script sure takes a while to run. I think performance is an issue.
Signature · 16 lines
Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, steve at picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." ------------------------------------------------------- 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 10 lines · Stephen Williams
Quoted 2 lines · [email protected] said:
How often do you connect a new USB or PCI device? If it takes a full second to react, that's OK; and Linux is usually faster than that.
When I was running on a 66MHz system w/ 128Meg RAM, it took on the order of 30 seconds to get around to invoking fxload. The initial execute of
/sbin/hotplugmay be quick, but that script sure takes a while to run. I think performance is an issue.
Never said it wasn't an issue ... just pointed out an assumption that optimizing for hundreds/thousands of events per second was the wrong way to go. Most systems don't have that many events in an entire day, except maybe when they reboot.
Systems that are "under-powered" have other tools available, like having /sbin/hotplug be a custom C program. Hmm, where have I heard of such a thing before, Greg? :)
- db
-------------------------------------------------------
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 10 lines · Stephen Williams
Quoted 2 lines · [email protected] said:
How often do you connect a new USB or PCI device? If it takes a full second to react, that's OK; and Linux is usually faster than that.
When I was running on a 66MHz system w/ 128Meg RAM, it took on the order of 30 seconds to get around to invoking fxload. The initial execute of
/sbin/hotplugmay be quick, but that script sure takes a while to run. I think performance is an issue.
Quoted 3 lines · [email protected] said:
Systems that are "under-powered" have other tools available, like having
/sbin/hotplugbe a custom C program. Hmm, where have I heard of such a thing before, Greg? :)
OK, temper-tantrum follows...
A CPU is pegged in my K-WizzyHz workstation doing a Verilog simulation or some image processing, and I hotplug a camera to get more images. Now /sbin/hotplug starts running a bunch of processes, causing a lot of kernel activity to dispatch the hotplug event to umpteen processes, fiddling with a zillion minor configuration files and subscripts until it gets figured out and a kernel module for a USB mass storage device is loaded, all the while thrashing caches and invoking page allocations- deallocations, and disrupting the background task, not to mention the desktop.
A ridiculous burden is a ridiculous burden no matter how fast the host system. I want my super-system doing *my* work, not spending barrels of mips and I/O cycles picking its nose.
I used my earlier mentioned 66MHz system to receive high resolution 8.5x11" color images, several images per second; yet plugging in a minor USB device was a major disruption for half a minute. Something is very wrong with this picture.
Incidentally, with REMOVER support, unplugging that minor device was nearly instantaneous on this "under-powered" machine. So getting the event to a process and dispatching it should be fast. It's been a while since I've been in the guts of the hotplug scripts, but my impression remains that they are in desperate need of diet, even for the normal case.
Signature · 16 lines
Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, steve at picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." ------------------------------------------------------- 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 3 lines · Stephen Williams
It's been a while since I've been in the guts of the hotplug scripts, but my impression remains that they are in desperate need of diet, even for the normal case.
Patches are always welcome :)
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 · [email protected] said:
Considering that I've not heard any other complaints about speed in the couple years they've been in use, "desperate" is wrong.
It's possible my perceptions are out of date. Said project of mine was finished a year or so ago.
Signature · 16 lines
Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, steve at picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." ------------------------------------------------------- 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 3 lines · Stephen Williams
A ridiculous burden is a ridiculous burden no matter how fast the host system. I want my super-system doing *my* work, not spending barrels of mips and I/O cycles picking its nose.
Sure, so do we all. On the other hand, it's quite understandable that even just disk access on that under-powered 66 MHz machine could disrupt everything else going on. That was certainly my experience running Linux on such a box. (It was a "super-system" maybe ten years ago, but today it's below even low-end...)
Quoted 4 lines
It's been
a while since I've been in the guts of the hotplug scripts, but my impression remains that they are in desperate need of diet, even for the normal case.
Considering that I've not heard any other complaints about speed in the couple years they've been in use, "desperate" is wrong. Demonstrably, there is no real performance problem -- today, on typical Linux systems.
But regardless, patches to speed things up can be accepted.
- Dave
-------------------------------------------------------
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