Gentoo Archives: gentoo-dev

From: Nicolas Sebrecht <nsebrecht@×××××.fr>
To: gentoo-dev@l.g.o
Cc: Nicolas Sebrecht <nsebrecht@×××××.fr>
Subject: [gentoo-dev] Re: udev and /usr
Date: Mon, 19 Sep 2011 08:04:35
Message-Id: 20110919080300.GA2401@nicolas-desktop
In Reply to: [gentoo-dev] Re: udev and /usr by Duncan <1i5t5.duncan@cox.net>
1 The 18/09/11, Duncan wrote:
2
3 > > I don't see any added benefit from using DBUS on my servers.
4
5 Insterstingly, Duncan just answered your question...
6
7 > Interesting question. I hadn't seen the suggestion until this thread,
8 > either, and it bothered me too.
9
10 From here:
11
12 > With a moment's thought, I decided I could probably return to a semi-
13 > static dev setup reasonably easily. I'd potentially turn on the early-dev
14 > option in the kernel that I still have off, ATM, which presumably would
15 > mount a tmpfs on dev and populate it with the earliest devices. After
16 > that, if necessary, I'd copy the existing udev-created nodes out to a
17 > persistent state dir, and copy them back in with a little init-time
18 > script of my own. As long as the device ordering remains stable, this
19 > could include by-label, etc, symlinks, or I could simply kill the by-
20 > label, by-uid stuff in fstab, and go back to traditional devices there,
21 > too.
22 >
23 > Either that, or simply go back to a static /dev entirely.
24 >
25 > People with dynamic ordered devices may have to devise their own scripts,
26 > tho, or perhaps more likely, fork off udev from the pre-union state.
27
28 ...to here.
29
30 > But it's also possible that's far enough in the future that we can't
31 > really answer the question now, since technology will have changed enough
32 > to make an answer now look senseless, then. Consider trying to answer
33 > the question in terms of the kernel devfs back before udev. The tech
34 > simply changed and those answers wouldn't really work, today.
35
36 Upstream changes the init process is done. So, you're free to either:
37
38 stick to upstream (with best long term support);
39
40 or
41
42 fork off upstream (requires knowledges, manpower and time);
43
44 or
45
46 go back to 1960 with a full/partial static /dev (asking to manually
47 maintain the crap).
48
49 See the benenfit, now?
50
51 --
52 Nicolas Sebrecht