Re: [ANNOUNCE] udev 0.1 release

[Greg KH]

On Fri, Apr 11, 2003 at 11:31:28AM -0700, Kevin P. Fleming wrote:
> 
> OK, this is all fun and games, but this is a valid point. All it takes for 
> the driver for a Fibre Channel host adapter to load, and enumerate the 
> devices it can see. In a matter of seconds many hundreds or thousands of 
> disk devices could be registered with the kernel.

Sure, the kernel can handle spawning hundreds or thousands of tasks all
at once, it's not a problem.

> This is definitely an issue that will need to be addressed, and I think 
> Oliver's suggestion of using a pipe (i'm going to say it: like devfs did 
> :-) to forward the events to /sbin/hotplug in a FIFO fashion makes some 
> sense.

I agree too.  Having /sbin/hotplug send events to a pipe where a daemon
can get them from makes a lot of sense.  It will handle most of the
synchronization and spawning a zillion tasks problems.

> I have also been considering this issue from another angle; I am 
> working on userspace partition discovery, which will be driven by 
> /sbin/hotplug (and udev, probably). I have concerns that the following 
> scenario will cause problems, if not extreme problems:
> 
> - kernel driver finds an IDE drive, registers it and the hotplug event 
> happens
> - udev gets called and gives it device node /dev/discs/disc0 (or whatever)
> - /sbin/hotplug calls userspace partition discovery, which opens the device 
> and scans for partitions
> - if any partitions are found, they are registered with the kernel using 
> device-mapper ioctls
> - because these new "mapped sections" of the drive are _also_ usable block 
> devices in their own right, they generate hotplug events
> - because these hotplug events are for new block devices, userspace 
> partition discovery will get called _again_ to handle them (it may not find 
> anything (the normal case), but this model will support nearly infinite 
> levels of partitioning on any block device supported by the kernel)
> 
> What happens if these secondary hotplug events occur while /sbin/hotplug 
> has not yet finished processing the first one? Ignoring locking/race issues 
> for the moment, I'm concerned about memory consumption as many layers of 
> hotplug/udev/kpartx/etc. are running processing these events.

Yes, this can quickly get recursive up to a point.  There will never be
an infinite number of partitions, so we will eventually quiet down.

> Of course, another possibility I'll look into this weekend is to actually 
> have kpartx run as a daemon and receive messages over D-BUS, instead of 
> being invoked directly by /sbin/hotplug. This would mean it could serialize 
> the events itself and reduce some of the load (if D-BUS supports message 
> queueing, which I believe it does).

Problem is I don't think we can use D-BUS messages during early boot,
before init is called, so we still have to be able to handle startup
issues.  But hopefully the D-BUS code can be small enough to possibly be
used in this manner, I haven't checked that out yet.

> Actually, here's another thought: have the kernel continue to call 
> /sbin/hotplug for every event, just as it does now. However, /sbin/hotplug 
> would do _nothing_ but translate that into D-BUS messages and post them. 
> udev, kpartx, etc. would all just be D-BUS clients that would respond to 
> their messages as they are received.

That's another possibility too.  This is getting interesting :)

thanks,

greg k-h