[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:32:18 +0200
    Kay Sievers <> wrote:

    > On Fri, Sep 18, 2009 at 16:25, Arjan van de Ven <>
    > wrote:
    > > On Fri, 18 Sep 2009 16:11:16 +0200
    > > Kay Sievers <> wrote:
    > >
    > >> On Fri, Sep 18, 2009 at 16:09, Arjan van de Ven
    > >> <> wrote:
    > >>
    > >> > frankly, modprobe should call the settle.
    > >>
    > >> We call modprobe from udev, and will have fun with such a solution.
    > >>
    > >
    > > too bad you cut my next sentence which said that there needed to be
    > > a way to opt out of that.
    > Too bad, bad we don't have control over all the udev rules out there
    > doing that, which will dead-lock then. And too bad that when udev
    > calls modprobe we still don't solve the races. Too bad that calling
    > "settle" waits for all events and you can never know when loading a
    > module what to wait for and what not. It's just not a close to a
    > solution that is doing any good. What's the point of all these weird
    > workarounds you are proposing? I think it's properly solved already.

    please chill out. your attitude is exactly why several folks are giving
    an allergic reaction. every other sentence for you is either extreme
    defensive or attacking, rather than constructive discussion.

    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)
    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)
    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.

    (to answer your "we are perfect" dream:
    you solved the "modprobe loop; losetup" example.
    you did not solve the "modprobe i915 ; startx" example.

    Arjan van de Ven Intel Open Source Technology Centre
    For development, discussion and tips for power savings,

     \ /
      Last update: 2009-09-18 16:47    [W:0.025 / U:8.580 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site