1 |
On Sat, 25 May 2013 11:54:48 +0200 |
2 |
Luca Barbato <lu_zero@g.o> wrote: |
3 |
|
4 |
> since the whole discussion got somehow sidetracked [SNIP], I'm back |
5 |
> to the other part of it: switching the actual init implementation. |
6 |
|
7 |
Thank you very much. |
8 |
|
9 |
> Since efi at least some people started to put in the kernel the |
10 |
> bootargs and we have at least few new options brewing for init, some |
11 |
> are small impact (bootchar, bb-init-openrc and runit-openrc) some are |
12 |
> more invasive (runit and systemd). |
13 |
> |
14 |
> In those setup changing bootargs requires a kernel rebuild and some |
15 |
> effort, while the eselect approach stays completely transparent. |
16 |
|
17 |
When we can edit the bootloader, we really shouldn't neglect this |
18 |
option. There are specific situations (like you mention EFI) where this |
19 |
may not be possible, but in that case we can just expect our users to |
20 |
chroot into their system and rebuild the kernel. These users are likely |
21 |
more used to do that because in my own experience if you mess part of |
22 |
EFI up you need to do this anyway; there's one option we forget about |
23 |
here though, EFI users can build a second smaller minimally adjusted |
24 |
defconfig kernel that ends up loading the default init system if they |
25 |
wish to repair their system without chrooting. |
26 |
|
27 |
So, please see the /sbin/einit suggestion in Bug 465236 at Comment 34 |
28 |
at https://bugs.gentoo.org/show_bug.cgi?id=465236#c34 which documents a |
29 |
sane alternative that allows users to load the default init system of |
30 |
Gentoo through their boot loader if they wish to do. This suggestion |
31 |
doesn't kill the eselect approach, but goes side-by-side with it; it |
32 |
effectively just names it /sbin/einit instead of /sbin/init to keep the |
33 |
default /sbin/init around. Another advantage is that users that don't |
34 |
want extra complexity as they don't want to compare or switch init |
35 |
systems will not get extra complexity added to their system. |
36 |
|
37 |
> For some switch we might not have just to change the init binary bit |
38 |
> also to do some other changes (e.g. use a different format for |
39 |
> inittab) |
40 |
|
41 |
Is there a specific need for this? I see this as possible regardless of |
42 |
how we end up doing this, or are there certain approaches that would |
43 |
disallow this? |
44 |
|
45 |
> - /sbin/init (or whatever linux currently calls by default with top |
46 |
> priority) |
47 |
|
48 |
Correct as far as I recall from patching that part of boot in the past. |
49 |
|
50 |
> should be either a symlink to the actual implementation or a |
51 |
> wrapper such as our gcc one. |
52 |
|
53 |
Wrapper sounds more safe to me since you allow more logic to be |
54 |
incorporated and aren't to restricted in what you can do with it early |
55 |
on, on the other hand a symlink would be a much more clean approach if |
56 |
you don't need more logic than just the symlink; although I'm not sure |
57 |
if the kernel loves a symlink for /sbin/init, haven't looked at that... |
58 |
|
59 |
> I like better the latter since it is overall safer. The former might |
60 |
> or might not work since linux has some fallback capabilities but |
61 |
> hadn't been tested. |
62 |
|
63 |
+1 I agree we should keep things safe when talking about our boot. |
64 |
|
65 |
> - init gets effectively switched only at boot/reboot |
66 |
|
67 |
As stated elsewhere in this ML thread, reboot is probably a bad idea to |
68 |
pursue; so that only leaves us with the boot option. When talking in |
69 |
the boot context there is likely no actual switch happening but it |
70 |
rather just kicks off the right progress instead. |
71 |
|
72 |
> eselect init |
73 |
> must keep track of the current active init and make sure the current |
74 |
> init configuration is used till the system reboots |
75 |
|
76 |
When we kick off the right init system at boot, we probably don't need |
77 |
to keep track of it separately; or at least not call eselect for that. |
78 |
|
79 |
Sounds like we would have two files like 'current_init' and 'boot_init' |
80 |
and `eselect init ...` would update 'boot_init'. Then, the first `init` |
81 |
invocation on boot would update 'current_init' with the value of |
82 |
boot_init; latter `init` invocations can then read out 'current_init', |
83 |
which is not to be touched by `eselect init ...`. |
84 |
|
85 |
> if we use the wrapper approach, it would pick up what's the new |
86 |
> init at boot and that would be enough for simple cases |
87 |
|
88 |
Ah, I think this is what I gave more detailed above. |
89 |
|
90 |
> hooks on reboot are still needed for more complex ones. |
91 |
|
92 |
Which complex cases would these hooks be needed on? |
93 |
|
94 |
> - we could try to not have the changes to the current init systems |
95 |
> ebuild or reduce them to the bare minimum (e.g. not |
96 |
> overwrite /sbin/init) |
97 |
|
98 |
The /sbin/einit approach that I linked near the start would help here. |
99 |
|
100 |
> # FOCUS |
101 |
> |
102 |
> My interest is mostly if not all on bb-init-openrc and slightly on |
103 |
> runit-openrc. |
104 |
> |
105 |
> There are enough people involved in systemd and since I still consider |
106 |
> it a dangerously frail implementation of a bad idea is better if I do |
107 |
> not touch it at all. |
108 |
> |
109 |
> My system with stock openrc gets from linux start to graphical login |
110 |
> in less than 6s and I'm not using Gnome so I do not have any reason |
111 |
> to use it beside comparing. |
112 |
|
113 |
Can we please keep information that may provoke a comparison off the ML? |
114 |
|
115 |
I'll give a neutral objective response why the init system doesn't |
116 |
matter for this, as I'm tired of seeing people sneak in data points |
117 |
like this. In your case it's intended to be good, but it can catch |
118 |
other people off guard that don't care to stay on topic. |
119 |
|
120 |
[[ Please avoid responding to this part of my mail, don't go OT. ]] |
121 |
|
122 |
I believe that any init system can help you reach the amount of time |
123 |
that you wish to achieve, after having pursued Arjan van de Ven's "one |
124 |
second for each phase" [1] (not an actual quote but an idea) approach |
125 |
long time I am down to a two second boot [2] till TTY login, I type my |
126 |
user and password and a second later I am in my graphical environment. |
127 |
|
128 |
On average I can't call myself rich as I'm still a student, so apart |
129 |
from a small SSD and an average CPU this doesn't require much hardware; |
130 |
or in other words I do not intent to brag here. In fact, I'm willing to |
131 |
help anyone who wishes to obtain similar results. |
132 |
|
133 |
The above is using, as you may guess, systemd because of certain |
134 |
details (eg. sockets); but that DOESN'T mean that with some simple |
135 |
hacks the same can't be achieved on OpenRC and your example is close |
136 |
enough to proof that it would indeed be quite possible to do so. |
137 |
|
138 |
The difference here is extremely minor anyway; most time is gained by |
139 |
what you end up killing than by choosing an alternative init system, |
140 |
as you can see these sockets aren't making up a huge difference at all. |
141 |
|
142 |
When there are multiple similar tools to accomplish something, it does |
143 |
not depend on how a certain tool is implemented, but rather on which one |
144 |
fits you best and how you use it. Look at the text editor you use; give |
145 |
it to your family, colleagues and friends and see how they struggle. |
146 |
|
147 |
[[ Please avoid responding to this part of my mail, don't go OT. ]] |
148 |
|
149 |
Please don't reply; I won't read it, I won't respond to it and it will |
150 |
not benefit this discussion, its reporter or anyone else participating |
151 |
in any way. You're free to contact me outside of the ML if you are |
152 |
interested in optimizing your boot, any other replies go to /dev/null. |
153 |
|
154 |
I wouldn't mind if you cut my mail in half and /dev/null-ed it too. :) |
155 |
|
156 |
TL;DR: There's no use in comparing boot times between init systems; I |
157 |
hope that anyone who continues to discuss in this thread or any future |
158 |
thread will not delude themselves to useless uneducated flame wars, |
159 |
whether it is boot time or anything else that you could call "better". |
160 |
What is "better" anyway? It's better for you, but not for everyone... |
161 |
|
162 |
[1]: http://lwn.net/Articles/299483 |
163 |
|
164 |
LPC: Booting Linux in five seconds |
165 |
|
166 |
[2]: http://i.imgur.com/wnod9R6.png |
167 |
|
168 |
Bootchart2: Small example of how my system boots these day. |
169 |
|
170 |
Yes, small, it doesn't allow you to change the scale at which you |
171 |
save. Given the result I'm too bored to fix this any further. |
172 |
|
173 |
[[ Please avoid responding to this part of my mail, don't go OT. ]] |
174 |
|
175 |
-- |
176 |
With kind regards, |
177 |
|
178 |
Tom Wijsman (TomWij) |
179 |
Gentoo Developer |
180 |
|
181 |
E-mail address : TomWij@g.o |
182 |
GPG Public Key : 6D34E57D |
183 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |