Designing a new init: low level communication

[Erich Schubert]

Hi,
> > 4. shared memory and sysv semaphores, or sysv messages
> IPC?
Yes, that is what is called SysV IPC.

> > write "montior stdout,stderr" to the "toinit" fd, then read on "frominit"?
> 
> What does the daemon read from init in monitor mode?

E.g. the output and stderr of other programs?
But we don't really need frominit, do we - we can just use stdin maybe?

> init receives stdout,stderr anyway. Plugins can subscribe to those
> streams, per daemon or as a whole. Then a plugin would handle simple
> status output to the console, another could handle LSB output,
> a third could handle a splashscreen.

Don't use the term plugin, which is somewhat used to linked-in stuff.
I really do not want this stuff as plugins. Take the unix approach and
make it separate processes strung together my sockets or pipes.
What do you mean by "LSB output"?

> I quite like the idea of using FDs for this.

[udev hiding /dev, including our socket]
> I think it would work. If it aquired the filehandle, it will still
> hold it even if udev now "obscures" the hierarchy. For the same
> reason that all processes can still use files even after you
> unlink() them.

And how is $userapplication-that-needs-to-start-a-service going to acces that?
It's not like init is using that fifo to talk to itself.

> also sprach Sven Mueller <debian at incase.de> [2005.08.29.2129 +0200]:
> > To each his own. I would not forget about "runlevels" (I currently don't
> > have a better name for it, perhaps "states" or "(service) collections"?)
> profiles :)

There is nothing wrong with the term "runlevels". It's not being
confused with something else, there is no real difference between what
we are going to call runlevels and what SysV calls runlevels, except
sysv only allows 1-digit runlevels, and is a PITA to configure.
You could probably convince me to "runstates", since the levels aren't
really ordered or hierarchical. But no generic terms please, that are
used anywhere else!

Back to the FDs. There are quite some unresolved issues with that yet.
So don't be happy too quick. The "needs" approach has some really nice
things, but assume we want to have the following run script:
---
#!/bin/sh
[ -x /usr/sbin/postgrey ] && need daemon/postgrey
exec /usr/lib/postfix/master
---
Sounds like a reasonable way to request postgrey to be up, doesn't it?
But how is this going to talk back to init? Using a fixed FIFO like
/lib/myinit/myfifo works just fine with some lock-spinning, though.
While the FD approach might be nice, it won't work. (Won't it leave
our init with too many open filedescriptors, too - how does init know
when to close an fd?)

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