Designing a new init: low level communication

[a-aa]

Erich Schubert wrote:

>Hi,
>  
>
>>>Hmm... that would be an option to solve communication, too - the core
>>>parts all retain a fd to talk to the main init process, the launchers
>>>close that fd for the actual daemons.
>>>If we find a configuration format (shell scripts are difficult then)
>>>that can deal with the fd, that would be nice.
>>>
>>>      
>>>
>>Could you give me an example?  Not 100% sure I understand how you mean.
>>    
>>
>
>fd 0 = stdin
>fd 1 = stdout
>fd 2 = stderr
>fd 3 = to init
>fd 4 = from init
>
>Before a launch helper execs the real daemon, it closes fd 3 and 4.
>If it's e.g. a monitor and not a launch helper (e.g. a "runlevel"
>manager or the dbus connector) it will keep these fds open, and
>recieve notices from init on fd 4, and send commands to it on fd 3.
>  
>
And say you want to monitor all output from all daemons?  I like a
event/hook based system where plugins/programs can hook into events much
better than every service having to specifically say "you use this".

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