Re: [PATCH] Remove broken by design and by implementation devtmpfs maintenance disaster

[Arjan van de Ven]

On Fri, 18 Sep 2009 16:32:18 +0200
Kay Sievers <kay.sievers@xxxxxxxx> wrote:

> On Fri, Sep 18, 2009 at 16:25, Arjan van de Ven <arjan@xxxxxxxxxxxxx>
> wrote:
> > On Fri, 18 Sep 2009 16:11:16 +0200
> > Kay Sievers <kay.sievers@xxxxxxxx> wrote:
> >
> >> On Fri, Sep 18, 2009 at 16:09, Arjan van de Ven
> >> <arjan@xxxxxxxxxxxxx> 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, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/