Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Jun 2012 14:54:15 +0200
From: aep <>
To: <>, <>
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 

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 
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 
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 [] 
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 

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.