Designing a new init: low level communication
Giacomo A. Catenazzi
cate at debian.org
Mon Aug 29 08:16:35 UTC 2005
Random comments.
I think we resolve a lot of problem if we make a fs writable from the
beginning. I think it can be a ram fs (i.e. in /boot/init) that
save messages for /var/run (when /var is mounted), for logs, ...
(i.e. modprobe dependencies)
An other point, I think we should forget runlevel. lilo and linux support
since day 0 (?) named "level" (i.e. "single") [Note: "single" is not a
runlevel, is only a variable passed to init scripts that block boot early],
so I'd like to have "net/no-net x/no-x daemon/no-daemon...".
Portability? runlevels are already (but few) admin defined, so programs
should not call init with predefined number/chars.
ciao
cate
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
>
> 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
More information about the initscripts-ng-devel
mailing list