Greg KH announced his new hotplug based userspace project known as hotplug-ng. He explains, "this collection of code replaces the existing linux-hotplug package with very tiny, compiled executable programs, instead of the existing bash scripts." He goes on to add:

"But why redo this all in .c code? What's wrong with shell scripts? Nothing is wrong with shell scripts, unless you don't want to have an interpreter in your initramfs/initrd and you want to provide /sbin/hotplug and autoload module functionality. Or if you have a huge box that spawns a zillion hotplug events all at once, and you need to be able to handle all of that with the minimum amount of processing time and memory."

Greg noted that he unscientifically noticed a speedup in how long it took for the proper module to be loaded after a usb devices was plugged into his slow laptop. With the old bash based hotplug scripts, this took about 2 seconds. With his new c-based hotplug-ng program, it took less than 1 second. In response to some clarification questions, he replied, "I do realize the whole hotplug process is getting a bit complicated. I hope to write up some good documentation on what all is involved to help clear up some of the confusion that the combination of udev, udevsend, udevd, hal, /etc/hotplug.d/, /etc/dev.d/, and /sbin/hotplug have caused lately."

From: Greg KH [email blocked]
To:  linux-hotplug-devel, [email blocked]
Subject: [ANNOUNCE] hotplug-ng 001 release
Date: 	Thu, 10 Feb 2005 16:40:33 -0800

I'd like to announce, yet-another-hotplug based userspace project:
linux-ng.  This collection of code replaces the existing linux-hotplug
package with very tiny, compiled executable programs, instead of the
existing bash scripts.

It currently provides the following:
	- a /sbin/hotplug multiplexer.  Works identical to the existing
	  bash /sbin/hotplug.
	- autoload programs for usb, scsi, and pci modules.  These
	  programs determine what module needs to be loaded when the
	  kernel emits a hotplug event for these types of devices.  This
	  works just like the existing linux-hotplug scripts, with a few
	  exceptions.

But why redo this all in .c code?  What's wrong with shell scripts?
Nothing is wrong with shell scripts, unless you don't want to have an
interpreter in your initramfs/initrd and you want to provide
/sbin/hotplug and autoload module functionality.  Or if you have a huge
box that spawns a zillion hotplug events all at once, and you need to be
able to handle all of that with the minimum amount of processing time
and memory.

So, how small are these programs?  Take a look:
   text    data     bss     dec     hex filename
   4669      32     124    4825    12d9 hotplug
   5077       8     348    5433    1539 module_pci
   4925       8     412    5345    14e1 module_scsi
   5349       8     348    5705    1649 module_usb

Those are all static binaries, linked with klibc (which is included in
the hotplug-ng package, just like udev.)

This compares to the following bash scripts:
-rwxr-xr-x  1 root root  4412 Feb 10 15:28 /sbin/hotplug
-rw-r--r--  1 root root   702 Sep 24 08:04 /etc/hotplug/blacklist
-rw-r--r--  1 root root  5293 Sep 24 08:04 /etc/hotplug/hotplug.functions
-rwxr-xr-x  1 root root  3739 Sep 24 08:04 /etc/hotplug/pci.agent
-rwxr-xr-x  1 root root  1459 Sep 24 08:04 /etc/hotplug/scsi.agent
-rwxr-xr-x  1 root root 13466 Sep 24 08:04 /etc/hotplug/usb.agent
-rw-r--r--  1 root root 39306 Sep 24 08:04 /etc/hotplug/usb.distmap
-rw-r--r--  1 root root  4364 Sep 24 08:04 /etc/hotplug/usb.handmap
-rw-r--r--  1 root root   189 Sep 24 08:04 /etc/hotplug/usb.usermap

All of which are loaded into memory for each hotplug event (for specific
hotplug events, only that bus type of file is loaded.)

But what about speed?  With a completely unscientific measurement on my
old, slow laptop, it takes about 2 seconds from the time I plug a usb
device into the machine, for the proper module to be loaded.  With the
hotplug-ng program, it takes less than a second.

And for those of you who might remember the old dietHotplug program that
also did the same thing in a tiny amount of space, this project
obsoletes that one.  dietHotplug had to be rebuilt for every kernel that
was used on the system, hotplug-ng uses the ability for modprobe to
determine the module that needs to be loaded based on the module
aliases[1].

The code can be found at:
	kernel.org/pub/linux/utils/kernel/hotplug/hotplug-ng-001.tar.gz
for those who wish to poke around in it.

I still have a few more programs to write to get it up to the same
functionality as the existing hotplug scripts (firmware, ieee1392, etc.)
but those will be done soon.  I'd like to get people's comments on the
idea, and welcome suggestions and even patches :)

hotplug-ng development is done in a BitKeeper repository located at:
	bk://linuxusb.bkbits.net/hotplug-ng

If anyone ever wants a tarball of the current bk tree, just email me.

thanks,

greg k-h

[1] modprobe as it currently works stops loading modules when it finds
an alias that matches.  This does not work for drivers that claim to
support "all devices" and then later on fail on devices that they really
don't support.  For that, all matching drivers need to be loaded for the
system to work properly.  The linux-hotplug scripts handle this
correctly, so if you rely on this functionality, please stick with that
package for now.  I'll be modifying modprobe to add this feature in the
near future.



From: Greg KH [email blocked]
Subject: Re: [ANNOUNCE] hotplug-ng 001 release
Date: 	Thu, 10 Feb 2005 16:52:58 -0800

On Thu, Feb 10, 2005 at 04:40:33PM -0800, Greg KH wrote:
> I'd like to announce, yet-another-hotplug based userspace project:
> linux-ng.

Bah.  The name is hotplug-ng.  Sorry about that...

greg k-h



From: Patrick McFarland [email blocked]
Subject: Re: [ANNOUNCE] hotplug-ng 001 release
Date: 	Thu, 10 Feb 2005 20:07:23 -0500

Greg KH wrote:
> I'd like to announce, yet-another-hotplug based userspace project:
> linux-ng.  This collection of code replaces the existing linux-hotplug
> package with very tiny, compiled executable programs, instead of the
> existing bash scripts.
> 
> It currently provides the following:
> 	- a /sbin/hotplug multiplexer.  Works identical to the existing
> 	  bash /sbin/hotplug.
> 	- autoload programs for usb, scsi, and pci modules.  These
> 	  programs determine what module needs to be loaded when the
> 	  kernel emits a hotplug event for these types of devices.  This
> 	  works just like the existing linux-hotplug scripts, with a few
> 	  exceptions.
> 
> But why redo this all in .c code?  What's wrong with shell scripts?
> Nothing is wrong with shell scripts, unless you don't want to have an
> interpreter in your initramfs/initrd and you want to provide
> /sbin/hotplug and autoload module functionality.  Or if you have a huge
> box that spawns a zillion hotplug events all at once, and you need to be
> able to handle all of that with the minimum amount of processing time
> and memory.

Wow, thats pretty awesome. Just the other day I said, "Why is hotplug written 
in sh? Isn't that horribly inefficient way of handling something that needs to 
be done quickly using the least amount of resources possible?" It seems you 
were reading my mind.

Please, continue this project and encourage distros to switch to it (when it 
exceeds hotplug in functionality and stability). Ubuntu currently is trying to 
reduce boot time, and I bet something like this would factor in (even a few 
seconds helps).

-- 
Patrick "Diablo-D3" McFarland || [email blocked]
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989



From: Greg KH [email blocked]
Subject: Re: [ANNOUNCE] hotplug-ng 001 release
Date: 	Thu, 10 Feb 2005 17:16:09 -0800

On Thu, Feb 10, 2005 at 08:07:23PM -0500, Patrick McFarland wrote:
> 
> Please, continue this project and encourage distros to switch to it (when 
> it exceeds hotplug in functionality and stability). Ubuntu currently is 
> trying to reduce boot time, and I bet something like this would factor in 
> (even a few seconds helps).

Thanks for the kind words.

All distros are trying to reduce boot time.  I don't think that the
module autoload time has been fingered as taking any serious ammount of
boot time due to it happening in the background of everything else.  But
yes, this should help it out (as long as we aren't trading I/O time for
CPU time, like it can happen if you don't have a populated modules.alias
file...)

And yes, I've been in contact with the Ubuntu developer already about
using this code, instead of dietHotplug.

thanks,

greg k-h



From: Bill Nottingham [email blocked]
Subject: Re: [ANNOUNCE] hotplug-ng 001 release
Date: 	Thu, 10 Feb 2005 22:18:23 -0500

Greg KH (gregkh@suse.de) said: 
> I'd like to announce, yet-another-hotplug based userspace project:
> linux-ng.  This collection of code replaces the existing linux-hotplug
> package with very tiny, compiled executable programs, instead of the
> existing bash scripts.
> 
> It currently provides the following:
> 	- a /sbin/hotplug multiplexer.  Works identical to the existing
> 	  bash /sbin/hotplug.

How does this interact with current usage of udevsend as the hotplug
multiplexer?

Bill



From: Greg KH [email blocked]
Subject: Re: [ANNOUNCE] hotplug-ng 001 release
Date: 	Thu, 10 Feb 2005 22:46:57 -0800

On Thu, 2005-02-10 at 22:18 -0500, Bill Nottingham wrote:
> Greg KH (gregkh@suse.de) said: 
> > I'd like to announce, yet-another-hotplug based userspace project:
> > linux-ng.  This collection of code replaces the existing linux-hotplug
> > package with very tiny, compiled executable programs, instead of the
> > existing bash scripts.
> > 
> > It currently provides the following:
> > 	- a /sbin/hotplug multiplexer.  Works identical to the existing
> > 	  bash /sbin/hotplug.
> 
> How does this interact with current usage of udevsend as the hotplug
> multiplexer?

First off, not everyone wants to use udev (I know, horrible thought...)
This provides those people a solution to a "I want a tiny /sbin/hotplug"
problem.

Also, udevstart working as /sbin/hotplug is great for keeping things in
order, which is important during normal operation.  But during the boot
sequence, the odds of getting out-of-order events, or even remove
events, is somewhat limited.  So, this /sbin/hotplug replacement can
work in an initrd/initramfs image when udevstart would be overkill.

And finally, even if you do use udevstart to manager /sbin/hotplug
events, you still need a module autoloader program.  This package
provides executables for that problem, if you don't want to (or you
can't) use the existing linux-hotplug scripts.  udev will never do the
module loading logic, so there's no duplication in this case.

Hope this helps.  I do realize the whole hotplug process is getting a
bit complicated.  I hope to write up some good documentation on what all
is involved to help clear up some of the confusion that the combination
of udev, udevsend, udevd, hal, /etc/hotplug.d/, /etc/dev.d/,
and /sbin/hotplug have caused lately.

thanks,

greg k-h

• Archive of above thread