[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
