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