Re: [gentoo-dev] eselect init

[Tom Wijsman <TomWij@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 8204 bytes --]

On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> since the whole discussion got somehow sidetracked [SNIP], I'm back
> to the other part of it: switching the actual init implementation.

Thank you very much.

> Since efi at least some people started to put in the kernel the
> bootargs and we have at least few new options brewing for init, some
> are small impact (bootchar, bb-init-openrc and runit-openrc) some are
> more invasive (runit and systemd).
>
> In those setup changing bootargs requires a kernel rebuild and some
> effort, while the eselect approach stays completely transparent.

When we can edit the bootloader, we really shouldn't neglect this
option. There are specific situations (like you mention EFI) where this
may not be possible, but in that case we can just expect our users to
chroot into their system and rebuild the kernel. These users are likely
more used to do that because in my own experience if you mess part of
EFI up you need to do this anyway; there's one option we forget about
here though, EFI users can build a second smaller minimally adjusted
defconfig kernel that ends up loading the default init system if they
wish to repair their system without chrooting. 

So, please see the /sbin/einit suggestion in Bug 465236 at Comment 34
at https://bugs.gentoo.org/show_bug.cgi?id=465236#c34 which documents a
sane alternative that allows users to load the default init system of
Gentoo through their boot loader if they wish to do. This suggestion
doesn't kill the eselect approach, but goes side-by-side with it; it
effectively just names it /sbin/einit instead of /sbin/init to keep the
default /sbin/init around. Another advantage is that users that don't
want extra complexity as they don't want to compare or switch init
systems will not get extra complexity added to their system.

> For some switch we might not have just to change the init binary bit
> also to do some other changes (e.g. use a different format for
> inittab)

Is there a specific need for this? I see this as possible regardless of
how we end up doing this, or are there certain approaches that would
disallow this?

> - /sbin/init (or whatever linux currently calls by default with top
> priority)

Correct as far as I recall from patching that part of boot in the past.

> should be either a symlink to the actual implementation or a
> wrapper such as our gcc one.

Wrapper sounds more safe to me since you allow more logic to be
incorporated and aren't to restricted in what you can do with it early
on, on the other hand a symlink would be a much more clean approach if
you don't need more logic than just the symlink; although I'm not sure
if the kernel loves a symlink for /sbin/init, haven't looked at that...

> I like better the latter since it is overall safer. The former might
> or might not work since linux has some fallback capabilities but
> hadn't been tested.

+1 I agree we should keep things safe when talking about our boot.

> - init gets effectively switched only at boot/reboot

As stated elsewhere in this ML thread, reboot is probably a bad idea to
pursue; so that only leaves us with the boot option. When talking in
the boot context there is likely no actual switch happening but it
rather just kicks off the right progress instead.

> eselect init
> must keep track of the current active init and make sure the current
> init configuration is used till the system reboots

When we kick off the right init system at boot, we probably don't need
to keep track of it separately; or at least not call eselect for that.

Sounds like we would have two files like 'current_init' and 'boot_init'
and `eselect init ...` would update 'boot_init'. Then, the first `init`
invocation on boot would update 'current_init' with the value of
boot_init; latter `init` invocations can then read out 'current_init',
which is not to be touched by `eselect init ...`.

> if we use the wrapper approach, it would pick up what's the new
> init at boot and that would be enough for simple cases

Ah, I think this is what I gave more detailed above.

> hooks on reboot are still needed for more complex ones.

Which complex cases would these hooks be needed on?

> - we could try to not have the changes to the current init systems
> ebuild or reduce them to the bare minimum (e.g. not
>   overwrite /sbin/init)

The /sbin/einit approach that I linked near the start would help here.
 
> # FOCUS
>
> My interest is mostly if not all on bb-init-openrc and slightly on
> runit-openrc.
>
> There are enough people involved in systemd and since I still consider
> it a dangerously frail implementation of a bad idea is better if I do
> not touch it at all.
>
> My system with stock openrc gets from linux start to graphical login
> in less than 6s and I'm not using Gnome so I do not have any reason
> to use it beside comparing.

Can we please keep information that may provoke a comparison off the ML?

I'll give a neutral objective response why the init system doesn't
matter for this, as I'm tired of seeing people sneak in data points
like this. In your case it's intended to be good, but it can catch
other people off guard that don't care to stay on topic.

[[ Please avoid responding to this part of my mail, don't go OT. ]]

I believe that any init system can help you reach the amount of time
that you wish to achieve, after having pursued Arjan van de Ven's "one
second for each phase" [1] (not an actual quote but an idea) approach
long time I am down to a two second boot [2] till TTY login, I type my
user and password and a second later I am in my graphical environment.

On average I can't call myself rich as I'm still a student, so apart
from a small SSD and an average CPU this doesn't require much hardware;
or in other words I do not intent to brag here. In fact, I'm willing to
help anyone who wishes to obtain similar results.

The above is using, as you may guess, systemd because of certain
details (eg. sockets); but that DOESN'T mean that with some simple
hacks the same can't be achieved on OpenRC and your example is close
enough to proof that it would indeed be quite possible to do so.

The difference here is extremely minor anyway; most time is gained by
what you end up killing than by choosing an alternative init system,
as you can see these sockets aren't making up a huge difference at all.

When there are multiple similar tools to accomplish something, it does
not depend on how a certain tool is implemented, but rather on which one
fits you best and how you use it. Look at the text editor you use; give
it to your family, colleagues and friends and see how they struggle.

[[ Please avoid responding to this part of my mail, don't go OT. ]]

Please don't reply; I won't read it, I won't respond to it and it will
not benefit this discussion, its reporter or anyone else participating
in any way. You're free to contact me outside of the ML if you are
interested in optimizing your boot, any other replies go to /dev/null.

I wouldn't mind if you cut my mail in half and /dev/null-ed it too. :)

TL;DR: There's no use in comparing boot times between init systems; I
hope that anyone who continues to discuss in this thread or any future
thread will not delude themselves to useless uneducated flame wars,
whether it is boot time or anything else that you could call "better".
What is "better" anyway? It's better for you, but not for everyone...

 [1]: http://lwn.net/Articles/299483

      LPC: Booting Linux in five seconds

 [2]: http://i.imgur.com/wnod9R6.png

      Bootchart2: Small example of how my system boots these day.

      Yes, small, it doesn't allow you to change the scale at which you
      save. Given the result I'm too bored to fix this any further. 

[[ Please avoid responding to this part of my mail, don't go OT. ]]

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]