Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] udev + /usr
Date: Mon, 12 Sep 2011 21:40:41
Message-Id: 20110912224532.04f835ee@rohan
In Reply to: Re: [gentoo-user] udev + /usr by Michael Schreckenbauer
1 On Mon, 12 Sep 2011 17:33:34 +0200
2 Michael Schreckenbauer <grimlog@×××.de> wrote:
3
4 > Every udev version works this way.
5 > Fixing udev to continue working with separate /usr is far from
6 > trivial imo. Changing some paths is not the way to go for sure.
7 > First of all, udev has to distinguish between "device not present"
8 > and "script error of some kind". Failing scripts have to be queued
9 > somehow for later execution. If a script keeps failing, it has to be
10 > removed from that queue, with a message to syslog or something like
11 > that. If udev needs a script in /usr/* to mount /usr then there's a
12 > chicken-egg-problem, which could be hard to solve (if possible at all
13 > without moving things from /usr/ to /). Note, that I am wild guessing
14 > here, I did not study the udev sources or any related script/rule :)
15
16 To expand on that:
17
18 udev running at early boot time and udev running later with a full
19 userspace mounted are very different things. udev should be able to
20 differentiate between these two phases and modify it's behaviour. Put
21 another way:
22
23 The thing that lays the foundation for the full userspace to be in
24 place *CANNOT* assume the existence of the full userspace. That's like
25 the wall assuming the roof must exist.
26
27 Furthermore, it's not at all a case that /usr must be mounted - that's
28 just an interesting artifact, and expression of where stuff is. The
29 correct description is more like "the script that udev launches must be
30 available to udev *when* udev launches it". I think concentrating on
31 the problem expressed in this wise would open the door to better
32 solutions.
33
34 I do like the idea of a phase 1 and phase 2 approach by udev - early
35 boot and full userspace running.
36
37 --
38 Alan McKinnnon
39 alan.mckinnon@×××××.com