On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato 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