[RFC] /sbin/hotplug multiplexor

[RFC] /sbin/hotplug multiplexor

[Greg KH]

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Oliver Neukum]

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Greg KH]

On Mon, Apr 14, 2003 at 09:16:45PM +0200, Oliver Neukum wrote:
> 
> > 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Oliver Neukum]

Am Montag, 14. April 2003 21:54 schrieb Greg KH:
> On Mon, Apr 14, 2003 at 09:16:45PM +0200, Oliver Neukum wrote:
> > > 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 :)

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Greg KH]

On Mon, Apr 14, 2003 at 10:09:56PM +0200, Oliver Neukum wrote:
> Am Montag, 14. April 2003 21:54 schrieb Greg KH:
> > On Mon, Apr 14, 2003 at 09:16:45PM +0200, Oliver Neukum wrote:
> > > > 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 :)
> 
> 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.orig	2003-04-14 13:27:28.513429040 -0700
+++ hotplug	2003-04-14 13:27:40.862551688 -0700
@@ -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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Oliver Neukum]

> > 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 :)

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Kevin P. Fleming]

Oliver Neukum wrote:

>>>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 :)
> 
> 
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Greg KH]

On Mon, Apr 14, 2003 at 11:11:01PM +0200, Oliver Neukum wrote:
> 
> > > 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 :)
> 
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Greg KH]

On Mon, Apr 14, 2003 at 02:24:48PM -0700, Kevin P. Fleming wrote:
> 
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Oliver Neukum]

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

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Robert Love]

On Mon, 2003-04-14 at 17:24, Kevin P. Fleming wrote:

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Greg KH]

On Mon, Apr 14, 2003 at 11:43:17PM +0200, Oliver Neukum wrote:
> 
> > > 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.
> 
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Oliver Neukum]

Am Montag, 14. April 2003 23:52 schrieb Greg KH:
> On Mon, Apr 14, 2003 at 11:43:17PM +0200, Oliver Neukum wrote:
> > > > 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.
> >
> > 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Greg KH]

On Tue, Apr 15, 2003 at 12:04:04AM +0200, Arnd Bergmann wrote:
> Oliver Neukum wrote:
> 
> > 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 $1
> done

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?

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Greg KH]

On Tue, Apr 15, 2003 at 12:19:26AM +0200, Oliver Neukum wrote:
> Am Montag, 14. April 2003 23:52 schrieb Greg KH:
> > On Mon, Apr 14, 2003 at 11:43:17PM +0200, Oliver Neukum wrote:
> > > > > 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.
> > >
> > > 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?

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.

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[David Brownell]

> On Mon, 2003-04-14 at 17:24, Kevin P. Fleming wrote:
>>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.


Robert Love wrote:
> See http://www.freedesktop.org/software/dbus/

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Stephen Williams]

david-b@pacbell.net 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.
-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[David Brownell]

Stephen Williams wrote:
> david-b@pacbell.net 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.

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Stephen Williams]

Stephen Williams wrote:
> david-b@pacbell.net 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.


david-b@pacbell.net said:
> 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?  :) 

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.


-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Greg KH]

On Thu, Apr 17, 2003 at 07:08:44PM -0700, Stephen Williams wrote:
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[Stephen Williams]

david-b@pacbell.net 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.
-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] /sbin/hotplug multiplexor

[David Brownell]

Stephen Williams wrote:

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


> 	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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel