[lkml]   [2003]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ANNOUNCE] udev 0.1 release
    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 :)


    greg k-h
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:34    [W:0.023 / U:9.252 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site