Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Anyone switched to eudev yet?
Date: Wed, 19 Dec 2012 09:31:25
Message-Id: 20121219112607.5f1b8f31@khamul.example.com
In Reply to: Re: [gentoo-user] Re: Anyone switched to eudev yet? by Michael Mol
1 On Tue, 18 Dec 2012 17:55:16 -0500
2 Michael Mol <mikemol@×××××.com> wrote:
3
4 > On Tue, Dec 18, 2012 at 9:33 AM, Alan McKinnon
5 > <alan.mckinnon@×××××.com> wrote:
6 > > On Tue, 18 Dec 2012 09:08:53 -0500
7 > > Michael Mol <mikemol@×××××.com> wrote:
8 > >
9 > >
10 > > This sentence summarizes my understanding of your post nicely:
11 > >
12 > >> Now, why is /usr special? It's because it contains executable code
13 > >> the system might require while launching.
14 > >
15 > > Now there are only two approaches that could solve that problem:
16 > >
17 > > 1. Avoid it entirely
18 > > 2. Deal with it using any of a variety of bootstrap techniques
19 > >
20 > > #1 is handled by policy, whereby any code the system might require
21 > > while launching is not in /usr.
22 >
23 > This is the solution I favor. Systemic structure which allows
24 > dependency leakage is indicative (to me) of lack of foresight and
25 > proper component role limitation, and ought to be fought.
26 >
27 > >
28 > > #2 already has a solution, it's called an init*. Other solutions
29 > > exist but none are as elegant as a throwaway temporary filesystem
30 > > in RAM.
31 >
32 > I find virtually nothing elegant about a temporary filesystem in RAM.
33 > It duplicates code that already exists on the system, and it
34 > represents and additional maintenance step in system upgrades. It
35 > seems almost a given that if someone is keeping multiple kernel images
36 > on a system, they're not updating the initr* for each when binaries
37 > that would be found in each are upgraded or rebuilt.
38
39 You could level the same criticism at boot loaders...
40
41 The also duplicate functionality in the main system they launch (albeit
42 read-only at least in legacy grub) in the fs drivers, are only used
43 briefly at boot-time and have to be maintained. True, the bootloader
44 doesn't contain a *copy* of the main system files which is where the
45 parallel breaks down.
46
47 init* may well suck, but they suck less than any other possible
48 solution. And they come with one more benefit - the community has
49 agreed on how they work so they form a standard of sorts
50
51 >
52 > In Debian, Ubuntu and others, this is handled by a post-install hook
53 > where the initr* image is rebuilt. To me, this honestly feels like a
54 > hack. In something like Gentoo, I'd rather see package placement
55 > driven by whether or not it will be needed to get all mount points
56 > mounted. If that means i18n databases under something like /boot/data,
57 > that seems reasonable. To me, the only cases where initr* feels like
58 > the right solution are things like netboot or booting from read-only
59 > media.
60
61 Let's not forget the prime reason why init* exists - so that binary
62 distros can boot and still have all kernel modules required at launch
63 time compiled as modules.
64
65 Bootstrap code and operation is ugly, always has been and always will
66 be. It also tends to be inflexible unless you use a slipstreaming
67 technique (my invented description of how init* works). I still think
68 the solution is elegant given the real-world requirements imposed on
69 systems.
70
71 >
72 > >
73 > > I should be clear that I do not necessarily support Lennart's
74 > > solutions, but I do support his perception of the problem (at least
75 > > partially). We cannot support situations where *launch* code is
76 > > haphazardly scattered in location X and this must always work for
77 > > all values of X. We already have a remarkably parallel situation
78 > > in /boot - in order to boot at all, the code running at that point
79 > > in time needs to be able to find stuff, and it finds it (by policy)
80 > > in what we will later call /boot. I see this /usr debate as the
81 > > same thing on a larger scale.
82 >
83 > --
84 > :wq
85 >
86
87
88
89 --
90 Alan McKinnon
91 alan.mckinnon@×××××.com

Replies

Subject Author
Re: [gentoo-user] Re: Anyone switched to eudev yet? Michael Mol <mikemol@×××××.com>