Designing a new init: low level communication

[Erich Schubert]

Hi,
Although I havn't gotten much (if any concrete) feedback on the
preferred way (or what you could imagine to be useful) of configuring
the init - here's my next question.

Maybe even more theoretical:
Again, assuming we're goging to end up writing a totally new init.
I guess most will agree that it would be nice to have a very small
core, and attach helpers to it "somehow", that do additional jobs.
This can be plugins, and one example is telinit.
We need to provide some means of communication for this case.
Since we want a more complex init, one-way communication will probably
not be sufficient.

I havn't fully investigated all options, and maybe I'm missing some.
More likely, I'll be missing some problem with them...

1. fifos.
The traditional approach is the /dev/initctl FIFO used by sysvinit.
This is a one-way link, and apps can lock() it to prevent interference
of write calls.
Minit does use two fifos, one for input, one for output. The semantics
is that you acquire a write lock on the "in" fifo (to init), then open
the "out" fifo for reading if you need/expect a reply. Example queries
are "give me the PID of service foo".

I don't know about runit or initng. Can someone please elaborate?
Afaict it has a plugin using sockets in /dev/initng (doesn't this
require a writeable filesystem?) and a plugin for initctl support.

Drawbacks:
- fifos need to be created before boot, so we don't need a writeable filesystem.
- only one client at a time

2. unix domain sockets
Drawbacks:
- need writeable filesystem
- portability issues with access control?
Pro:
- multiple connections possible

3. abstract unix domain sockets
(which have a filename starting with \0 and do not reside in the filesystem)
Drawbacks:
- portability issues (linux only?)
Pro:
- multiple connections possible
- no writeable filesystem needed (verified?)

4. shared memory and sysv semaphores, or sysv messages
Drawbacks:
- difficult semantics, signalling?
Pro:
- portable to BSD? (can anyone verify?)

Well, doesn't look to nice what I've found so far...
We could probably do a combined approach - use two fifos for the core
operations, like minit does, and do extended stuff (e.g. monitoring,
dbus connector) over unix domain sockets and abstract uds?

Anyone with lots of experience at this level?
Because I'd really like to have a minimal core init...

best regards,
Erich Schubert
--
    erich@(mucl.de|debian.org)      --      GPG Key ID: 4B3A135C    (o_
  To understand recursion you first need to understand recursion.   //\
  Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für   V_/_
        eine Stunde wie eine Heimat aus. --- Herrmann Hesse