Date: Mon, 11 Jun 2012 14:54:15 +0200 From: aep <aep@...s.org> To: <musl@...ts.openwall.com>, <dalias@...ifal.cx> Subject: Init system (Re: Re: Vision for new platform) I designed one based on the needs we had in previous embedded products, but got stuck because the project was killed and replaced by ubuntu upstart. Still there's plenty things that are interesting in that area, so i kept working on it in my free time. Since it's written in a high level language (clay) it will never be accepted by most of you, but i's still love some dicussion on the actual design of these things. We clearly agree that the general direction systemd is taking is very wrong. I believe they'll sooner or later realize on their own, and build another udev to fix it. On Sun, 10 Jun 2012 15:33:48 -0400, Rich Felker wrote: > And runlevels never really made any sense to me They do not, on a desktop where you usually want exactly two: 1) "boot to my favorite UI" and 2) "Give me a recovery shell." Hoever, on embedded devices, there are more init states which aren't covered by any currently existing software: - Charging, but not powered on - Fault recovery - Update cycle - Reboot from NVRAM Boot states with numbers, are clearly from the 60s. Upstart correctly replaces them with init "groups", however the control interface through dbus is too broken to use them. Neither can any of the existing software correctly make it's boot graph depend on hardware tables in the bootsector. This is very important for mass produced devices which get the same software for different hardware variants. Instead there's usually a second and third init process involved. Just like on the desktop where there is a "high level init system" executed when you are logged into your desktop thingy. My toy project solves this by putting the session controller in pid 1, and exposing the relevant bits to a comandline interface, which i call from .xinitrc The actual problem of init groups is not solved, since i don't care. But in a "real" product, i'd do something very similar to upstart. > Let's instead start from the perspective of problems to solve: > > 1. Initiating/controlling the boot process. > 2. Providing login prompts on console ttys. > 3. Managing system daemons. > 4. Handling insertion and removal of hardware. > 5. Handling changes to hardware status. Don't mix them together. This is a much much bigger problem then "start some daemon when i plug in a printer" Systemd solves this problem in a very crude and short sighted way. You still need a high level mechanic to actually do something with the printer. They just fire a signal over dbus and let someone else worry with the problem while the "someone else" has to invent it's own hardware abstraction layer to get anywhere. This is a receive for bloat and painful design. Instead my toy init exposes no hardware events. It merely acts on behalf of any arbitrary hardware controller, which can be multiple. It assumes that there is something like mdev or udev. It exposes all the "services that can be started" like "printing", but never starts them based on anything except an explicit call to the start interface. Since in the core it exposes a ubus [http://unixbus.org/] service for each service to be started, permissions are simply solved with regular unix modes. While this is elegant, it has one major flaw, that is domain sockets in linux have no permission checking, requiring an additional ugly layer of extra checking on SCM_CREDS. I never solved that problem after i realized what a kind of person al viro is. He'd never accept a fix to the kernel unless it comes with $$$ attached. But... different story i suppose. > 6. Shutting down/rebooting the system. Note that the lack of high level policy bites you here a lot. I just type "witch halt" which brings down my session cleanly too, but every other init system requires a secondary high level init to be shut down first, otherwise you get "Not exited cleanly" warnings on your favorite BloatDE. No idea how other distros solve it, but archlinux has a really ugly "Sending kill to remaining processes" at the end of shutdown. For me this is a clear indication that shutdown is just horribly broken. > I'm generally of the opinion that trying to tightly integrate these > (largely unrelated) tasks just creates a lot of complexity and > lock-in > with little or no benefit. I just read that after complaining that you did, haha. > In contrast, for problems #1 and 2, I have > a 22-line (C) init program that does nothing but run the boot script > and reap orphaned zombies, and a 34-line (C) program that repeatedly > re-runs a program in a new session every time it exits. The latter, > combined with a 14-line (shell script) getty program, is sufficient > to > handle all console logins. As i said in the beginning of this thread, everyone has their favorite hack. Creating something that works for everyone is much much harder. And clearly this is the part that needs to be solved. 22 lines C and a couple shell lines is how sysvinit started, and then quickly went out of control when trying to make the thing scale to every machine in the universe.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.