As I said in my previous post I’ve decided to use BusyBox to strip down a Gentoo system to a bare minimum for the device I’m working on right now. This actually allows for a lot of things to be merged into a single package, but at the same time it has another very interesting side effect.
One of the reasons why systemd has been developed is that the traditional init systems for Unix use shell scripts for starting and stopping the services, which is slow both due to the use of bash (which is known to be slow and bloated for the task) and the use of fork/exec model for new commands. While we’ve had some work done to get the init scripts reduced and working with alternative shells, namely dash, what I’m using now is a slightly different variation: everything is done through BusyBox.
This has more than just the advantage of its shell scripting being faster: when using a “fat” build of busybox, which includes most of the utilities used in Linux, including coreutils, which and so on so forth, the execution of commands such as cut, sed, and the like is no longer happening through fork/exec, but rather through internal calls, as BusyBox is a multi-call binary. And even if the call is so complex it has to fork for it (which doesn’t happen so often for what I can tell), the binary is already well in memory, relocated and all.
Up to now I only found one issue in OpenRC when booting this way, related to the sysctl init script, so I submitted a patch which is already in OpenRC now. I’m not yet done with removing the separate packages, so there might be more issues, and of course I’m only using a very small subset of init scripts, so I wouldn’t be able to tell whether it would work on a full desktop system.
But this would for sure be a worthy experiment for somebody at some point.
This is certainly a very interesting approach and has a lot of potential for quick boot. Will definitely keep an eye on this and glad your work for this company is making it back to OSS.
I’ve done this last year, when I (rather painfully) installed Gentoo on a PPC PowerBook 3400c with a 200 MHz PPC 603e and 80 MiB RAM, which of course made it very appealing to squeeze out anything I could.Memory might fail me since I don’t remember seeing errors that were due to using BB, other than when I accidentally included the BB-specific setfont in BB, which caused an error when running consolefont. I do remember that it was able to successfully boot me to a working bash, demons and whatnot.I didn’t get to play much with that computer because it required booting in MacOS to then reboot in Linux, which is slow, and because running emerge -vpuDNK @world would take several minutes each run.
Dude, you probably should check out the boot up on a typical arch linux installation. Arch boots way way faster than gentoo and yes it uses bash all the way for init scripts.. and the arch script does pretty much all the same things that the gentoo scripts does. The init scripts are written in shell script for a reason.. and that being that they are flexible and changable on the fly.
“way way faster” doesn’t seem to say much, I guess it all depends on what it’s doing and what you consider boot. Starting up network connections is not considered boot when you use NetworkManager, but we can’t consider the system up until network has booted.Given that the actual userland boot time for me here is something like three seconds (and almost a full one is spent waiting for DHCP to hand out an IP address), I’m pretty sure we’re on the verge of fast enough. I know that it wouldn’t be _this_ fast if it was booting with bash though (simply because I tried).I’m definitely not of the opinion to get rid of shell scripting in init script, for what it’s worth.
Right now http://en.gentoo-wiki.com/w… suggests to build busybox with ‘static’ useflag for initrams.AFAICT, this is due to pam dependency. Would a busybox built without that useflag with initramfs including libpam_misc.so.0 and libpam.so.0 and no other files from pam mostly working or plain broken ?If broken, what would be the minimal subset of pam files required to make it bootable and/or working ?
Unless you’re going to use @login(1)@ as provided by BusyBox, you definitely don’t want its pam USE flag enabled.I have it especially disabled on _all_ my systems, as I use busybox for recovery purposes only.
Diego, that is genius! It never would have occurred to me to use busybox instead. I’ve gotta try that out on my next build. :)(Also, what device are you hacking on with it?)
OpenRC + Busybox is used in http://alpinelinux.org/