Re: RFC: OpenRC as Init System for Debian
On Sat, 2012-04-28 at 02:29 +0200, Vincent Bernat wrote:
> OoO Vers la fin de l'après-midi du vendredi 27 avril 2012, vers 16:29,
> Svante Signell <svante.signell@telia.com> disait :
>
> > Apparently it can today ... with init scripts, which _new_ features will
> > be brought in for the _boot_ process. udev takes care of the events,
> > already today, right? More secure boot, faster boot (coreboot), better
> > debugging, simple ways of logging the boot massages, etc? Don't talk
> > about plug-and-p{r}ay, that is not interesting for _boot_: Found new
> > hardware, eh?
>
> But that's the whole point : new hardware pops up while booting. See for
> example a server that will need a 3G connection. The 3G connection will
> be done by some classic USB key. When the USB key is detected, udev
> triggers a script asking the USB key (which defaults to a mass storage
> device) to switch to "modem mode". Once it becomes a modem, the 3G
> connection can be initialized. Turning the USB key into a modem is
> taking some time. The USB key will be "disconnected", then
> "reconnected". SO, "found new hardware". ifupdown scripts were already
> run and filed with "interface not found".
Nice description, thanks. However, this is not necessarily part of the
_boot_ process!! This could/should happen _after_ the computer is up and
running, e.g. when starting X. You are not able to use your USB modem
until then anyway, and boot times should be as short as possible, not
having to wait for a dongle to connect to the wireless network. So, the
real problem is: How do you define the boot process of a computer. For
me it is when the kernel has been loaded by the boot media, memory,
graphics card, etc initialized. Some modules are needed for boot, other
modules can be loaded later. The only case I can see when you need a
network during the boot process is when booting from the network, and
for that you can predefine which modules to load.
> udev can run simple actions when a device appears but cannot run a chain
> of dependencies (start the 3G connection, run some daemon that needs
> Internet which in turn will trigger some client to this daemon to
> run). The solution is an event-based init. We want a reliable boot.
Then the functionality of udev should be extended, not dragging the
init scripts into this udev<->Linux kernel interaction. I think it
would be much better to isolate these two instead of having a third
(potentially buggy) software included.
> We are in 2012 and if a non-essential daemon blocks the boot (no working
> network), we have no way to get a getty to be run.
See the reply from Thomas Goirand.
Reply to: