1 |
On Wed, Dec 19, 2012 at 4:26 AM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
2 |
> On Tue, 18 Dec 2012 17:55:16 -0500 |
3 |
> Michael Mol <mikemol@×××××.com> wrote: |
4 |
> |
5 |
>> On Tue, Dec 18, 2012 at 9:33 AM, Alan McKinnon |
6 |
>> <alan.mckinnon@×××××.com> wrote: |
7 |
>> > On Tue, 18 Dec 2012 09:08:53 -0500 |
8 |
>> > Michael Mol <mikemol@×××××.com> wrote: |
9 |
|
10 |
[snip] |
11 |
|
12 |
>> > #2 already has a solution, it's called an init*. Other solutions |
13 |
>> > exist but none are as elegant as a throwaway temporary filesystem |
14 |
>> > in RAM. |
15 |
>> |
16 |
>> I find virtually nothing elegant about a temporary filesystem in RAM. |
17 |
>> It duplicates code that already exists on the system, and it |
18 |
>> represents and additional maintenance step in system upgrades. It |
19 |
>> seems almost a given that if someone is keeping multiple kernel images |
20 |
>> on a system, they're not updating the initr* for each when binaries |
21 |
>> that would be found in each are upgraded or rebuilt. |
22 |
> |
23 |
> You could level the same criticism at boot loaders... |
24 |
> |
25 |
> The also duplicate functionality in the main system they launch (albeit |
26 |
> read-only at least in legacy grub) in the fs drivers, are only used |
27 |
> briefly at boot-time and have to be maintained. True, the bootloader |
28 |
> doesn't contain a *copy* of the main system files which is where the |
29 |
> parallel breaks down. |
30 |
|
31 |
Bootloaders tend to be updated in a targeted or atomic fashion. This |
32 |
remains true even as they become more and more like full operating |
33 |
systems. |
34 |
|
35 |
> |
36 |
> init* may well suck, but they suck less than any other possible |
37 |
> solution. |
38 |
|
39 |
I disagree. I think defining boot stages, and fixing cross-stage |
40 |
dependency errors, is a far better solution. |
41 |
|
42 |
> And they come with one more benefit - the community has |
43 |
> agreed on how they work so they form a standard of sorts |
44 |
> |
45 |
>> |
46 |
>> In Debian, Ubuntu and others, this is handled by a post-install hook |
47 |
>> where the initr* image is rebuilt. To me, this honestly feels like a |
48 |
>> hack. In something like Gentoo, I'd rather see package placement |
49 |
>> driven by whether or not it will be needed to get all mount points |
50 |
>> mounted. If that means i18n databases under something like /boot/data, |
51 |
>> that seems reasonable. To me, the only cases where initr* feels like |
52 |
>> the right solution are things like netboot or booting from read-only |
53 |
>> media. |
54 |
> |
55 |
> Let's not forget the prime reason why init* exists - so that binary |
56 |
> distros can boot and still have all kernel modules required at launch |
57 |
> time compiled as modules. |
58 |
|
59 |
Another valid use case. |
60 |
|
61 |
> |
62 |
> Bootstrap code and operation is ugly, always has been and always will |
63 |
> be. It also tends to be inflexible unless you use a slipstreaming |
64 |
> technique (my invented description of how init* works). I still think |
65 |
> the solution is elegant given the real-world requirements imposed on |
66 |
> systems. |
67 |
|
68 |
And I still think that, outside of scenarios where workarounds don't |
69 |
exist, it's an ugly hack and a cop-out. |
70 |
|
71 |
-- |
72 |
:wq |