Designing a new init: low level communication

a-aa a-aa at hollowtube.mine.nu
Mon Aug 29 11:40:25 UTC 2005


Erich Schubert wrote:

>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
>  
>
You can use /dev, which means it's accessable from very early in the
boot, initng does this and it works well.  Also, are we sure this needs
a writable filesystem?  I think if the socket exists it might not, I
can't really remember ;)

>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...
>  
>
I have a bit of experience here, as initng has been trying out a few
here, fifo's were horrible and unix sockets worked very well, and we can
solve issues here either with initramfs on boot or by waiting until /dev
is mounted (which by initng is after the first script is launched).

How much do we want to support remotly though?  Do we want a plugin api
or a comunication api?  I imagine a comunication api would end up being
considerably more advanced and a lot harder to implement, but that could
be because I'm used to working with plugins ;)

>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
>
>_______________________________________________
>initscripts-ng-devel mailing list
>initscripts-ng-devel at lists.alioth.debian.org
>http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
>
>  
>




More information about the initscripts-ng-devel mailing list