[lkml]   [2009]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Remove broken by design and by implementation devtmpfs maintenance disaster
    On Fri, 18 Sep 2009 16:58:28 +0200
    Kay Sievers <> wrote:
    > > Lets be clear:
    > > 1) modprobe already does some serialization (right now on the kernel
    > >   side, but ideally we move that to modprobe binary so that we can
    > > skip that when we can)
    > We only serialize symbol linking I guess, and that window got pretty
    > small in recent kernels.

    more than that; there's also an async_synchronize_full() function call.
    I'd love to be able to move that down into modprobe.

    > > 2) udev today has a small design issue that is relatively easy to
    > > fix. Right now, the rules call modprobe manually, each and every
    > > one of them. What is needed is a MODPROBE += directive for these
    > > instead of the RUN += that is done today. This is not (just) for
    > > this issue here, but is essential to reduce the cost of udev. A big
    > > chunk of udev cost is in doing dozens and dozens of useless
    > > modprobe execs; the only way to solve this is by having a MODPROBE
    > > +=. (useless because the thing they modprobe doesn't exist)
    > That would help in which case? Which single event does do more than a
    > single modprobe call? What do you want to collect?

    DRIVER!="?*", ENV{MODALIAS}=="?*", RUN{ignore_error}+="/sbin/modprobe

    I don't want to "collect". What I want is to have udev check the module
    alias database directly for existence, rather than exec()ing modprobe
    100 times, which then reads in that same table, etc 100 times.

    if you measure things, these 100 aliases (of which maybe 5 cause a real
    module to load) causing 100 execs is a rather significant chunk of
    where the udev cost during boot goes.... from where I sit that makes it
    worth optimizing ;)

    > > 3) if we move synchronization for other things to modprobe, it might
    > > make sense to move the device node synchronization to it as well.
    > > Exactly for the scenario you described, to get a good, generic
    > > solution, that also makes sure that the permissions/ownership/etc of
    > > the device node is also the right one.
    > How do you know what to sync against, what to wait for? I'm pretty
    > sure the sync creation is much simpler and solves most of the problems
    > in the right way.

    it's only sync creation if the device init/registration is also sync.

    for performance I suspect we need to end with an *option* to just load
    all modules based on the device in the system, without waiting, and
    then at the end of loading all, say, 60 modules, wait before udev

    that is different than later on loading, say, the loop module by hand,
    where the user expects "full synchronization". The device node is a
    small part of that, and clearly a relevant part, but it all goes
    together. The moment modprobe synchronizes explicitly (albeit by
    default) for the device init, it can and likely could also sync the
    full device creation (so including owner/acl/selinux context etc),
    providing a solution to the problem you want, but including the
    owner/acl bits.

    I suspect you're now going "lalalala" ;-)

    but I'm not saying all of this to diss your devfs code. I'm saying that
    *regardless of* your code, modprobe likely needs to start doing
    these synchronization steps over time.

    Arjan van de Ven Intel Open Source Technology Centre
    For development, discussion and tips for power savings,
    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: 2009-09-18 17:15    [W:0.023 / U:47.736 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site