Ian Stakenvicius posted on Sun, 26 May 2013 10:58:24 -0400 as excerpted: > On 26/05/13 07:40 AM, Luca Barbato wrote: >> On 5/26/13 12:57 PM, Michał Górny wrote: >>> You are telling me that a wrapper, a thing that gets executed *every* >>> boot needs to do some random magic to know which init system was in >>> use and which one is supposed to be in use, and then conditionally >>> move around configuration files necessary for it to run. This is just >>> *INSANE*. >> >> I like to think it normal and the wrapper doesn't need to run every >> time but only when a switch had been requested. And only if you prefer >> doing the switch at boot time instead than at shutdown. >> >> > The way it's being proposed (and please correct me if i'm wrong), the > wrapper is a direct replacement binary (small C program) for all init > systems, and would based on some configuration file or whatnot determine > and exec the init system it's supposed to -- and make any other > necessary changes too, such as switching /etc/inittab) > > I don't know (outside of a script in the initramfs) how this would > otherwise be handled to cover all cases. I am curious though, if you > see a way to do this otherwise, what the implementation would look like?
Here's an idea I've not seen proposed yet. Make the wrapper function something like a cross between a simple bootloader and traditional single-user-mode. Normal mode, like the bootloader for many users, would be a default choice with (configurable) either a timeout of a couple seconds, or (say shift) key-held-down detection, thus no boot delay as if the key isn't down at the moment of detection, boot proceeds using the existing config. In the event of an init switchup, the user either sets an option before shutdown (much like the run-once defaults of grub, etc, set pre- shutdown), or selects switchup mode with the appropriate boot-time trigger (using the above mentioned timeout or key-down sensing). The special switchup mode would then operate much like single-user in terms of available functionality and the fact that it's a special mode used for system maintenance, but would (normally, with a drop-to-shell option as well) be rather more guided, presumably using a menu, again much like a bootloader, except that it's PID-1 instead of pre-kernel. Critical point #1 is that much like single-user mode, switchup mode would NOT run normally, but would be specifically selected, with either a reboot or simply starting the new init system at switchup mode exit. That gives switchup mode a lot more flexibility in terms of what's allowed, since it's no longer in the time-critical every-boot path, and because it's its own mode, it can mount / rw to make changes as necessary, with either a reboot to start the selected init-system or simply starting it normally, at switchup mode exit. And if anything goes wrong, simply select switchup mode at the next boot once again, and either revert to previous, for fix it. Critical point #2 is that the actual normal-mode wrapper would be very small both in terms of boot-time and code, thus both easy to debug, and not increasing boot time by much at all, particularly in key-down- detection mode where there'd be no timeout delay to tick down. A small binary that simply either runs the timout or detects key-down, before execing the normal init, is all that would run in a normal bootup. The complex functionality would only be invoked if switchup mode is chosen, as entirely separate functionality execed place of the normal init it would have otherwise execed. Meanwhile, switchup mode (again, a separate binary execed only if chosen from the tiny one designed to run inline at each boot) would have a menu with options to invoke scripts for each of the init-system choices offered, and a further fall-back to shell option. Each init-system package would then depend (perhaps conditionally based on an init-switcher USE flag) on the init-switcher package, and would ship one gentoo specific file, the switcher script, thus putting each switcher script under the control of the gentoo maintainers for that init- system package, who could set it up to be as simple or as complex as necessary for their init system. Those who needed a rw root to switch out various files could arrange for their switcher script to handle that, while those who could do without, possibly handling things later with their own native init-service, could do without the rw root bit. Similarly, switchup mode exit-time behavior, presumably either simply triggering a reboot, or starting the selected init-system directly, would be entirely under the control of the individual init-system package maintainers, via the switch-script they maintain. As a first bonus, even people who aren't interested in more than one init- system might find setting the init-switcher USE flag useful, especially on EFI systems, since it would give them the advantages of switchup mode, namely a drop to shell option as yet another alternative to single user mode, AND perhaps even MORE importantly, access to a more or less automated init-system restore option, triggered via selection of the same switcher script that would otherwise be run to switch between init- systems. Again, the contents of that init-system-specific switcher- script would be entirely under the control of the gentoo maintainers for that package, so they could do whatever fancy working-condition checks and restores from backup that they wanted. As a second bonus, switchup mode would be extremely flexible and extensible via these scripts, and I'd envision people writing extension scripts for all sorts of additional functionality. Backups while the system is quiesced? Hook for boot-chart and similar modes? A fast-boot special media-player mode? Something else exotic in mind? No problem! Hack up a special purpose switchup-mode script for it, and "the world's your oyster!" -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
