[cgl_discussion] Re: device enumeration

Greg KH greg at kroah.com
Thu Feb 6 21:32:27 PST 2003


On Fri, 07 Feb 2003 12:13:56 +1100, Steven Dake wrote:
> I still haven't :) come to my senses that /sbin/hotplug is the right
> solution.

I'm sorry, but I think you've lost this argument :)

> There are several problems with /sibn/hotplug which are 1) a
> process must be spawned to handle an event

Linux spawns processes faster than any other OS.

> 2) events take a long time to process through a shell script

So use a binary /sbin/hotplug if you care about speed.

> 3) even if /sbin/hotplug is binary C code it would still have 
> poor performance characteristics

Who cares about performance, this is _not_ a preformance criticial
situtaion.

> 4) calling a user
> space application from the kernel to process any sort of event, besides
> init, is just wrong, wrong I tell you.  I much prefer the idea of a
> hotswap manager user space application executing select() on a character
> device node and reading events via read or ioctl from the device node
> when a hot insert or removal event occurs.

Sorry, but that's where you differ from the other kernel developers.
/sbin/hotplug is conceptually much cleaner and nicer than having to 
do select() or ioctls.  Remember ioctls are basically depricated, and
you should not add new ones.

> This is exactly what we do for IPMI hot insert/remove events for our
> ATCA-like chassis, and it works quite well and fast (20 msec removal
> times from event to device removed from OS) without process spawn
> overhead.  This same solution using /sbin/hotplug would take 45 msec (I
> tried it out), and require us to include more event processing code in
> the kernel then we would need.

Who cares about the speed here?  I remember some discussion about speed
issues with regards to hotplug unplug disks, but that turned out to not
be a realistic issue (basically it was lazy testers) and not a real
requirement.

> Mark Bellon (mbellon at mvista.com) has implemented a user space database,
> API, and event transfer mechanism that sounds similiar to what your
> planning and I'd suggest talking to him about what we are doing in this
> space.  I really believe it would be in everyone's interest to work
> together towards a common solution that fits USB/PCI as well as CPCI and
> ATCA that keeps in mind the 4 points above about why /sbin/hotplug is
> inappropriate for fast event management.

I've been in contact with Mark in the past, and it's my fault that I
haven't followed up with him on some of the issues we've talked about.

The biggest issue with mvista's implementation is that it's built on
top of the chassis code, which is (imho) a horrible piece of code.  It
also doesn't take advantage of the driver model, which is the way to
go in 2.5 (yes, I know your implementation is only for 2.4, but sysfs
can be backported if you want to...)

So in short, /sbin/hotplug is here to stay and speed doesn't really
matter :)

thanks,

greg k-h




More information about the cgl_discussion mailing list