Re: [ANNOUNCE] udev 0.1 release

Greg KH
2003-04-11T18:53:29Z

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