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