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 |