Designing a new init: low level communication

[a-aa]

Just writing up which plugins initng currently has.

ash_launcher - a script launcher using a statically linked internal ash
to execute stuff.
bash_launcher - same using /bin/bash
chdir - doh
chroot - doh
cpout - Prints fancy output, collects stuff and makes sure we dont have
parallel stuff writing to stdout at the same time.
depend - handles dependencies
dllaunch - .. no clue :p, jimmy has added this fairly recently ;), think
it's a dlsym executor or something.
down - .. again, no clue
dparser - .. he's been busy
execve_launch - using execve to launch stuff I assume
find - parses ngc -u samba to ngc -u daemon/samba
initctl - handles backwards compatibility with /dev/initctl
interactive - interactive boot, allowing a user to say yes or no before
starting a service
iparser - parses .i files (our service format)
ngc2 - our control program, using unix sockets to comunicate with core
pause - handles sleep/usleep in services
pidfile - monitors pidfiles (actually waits until program ends/forks,
then checks pidfile and tags program as running if it finds one alive)
provide - handles provide=networking for example
readahead/readahead_makecache - I made this a seperate daemon but
haven't removed it from svn until I tell people where I put it :p
reload - allows full reload of initng
renice - nice keyword in service files
rlparser - runlevel parser
simple_launcher - handles start = /daemon/whatever
splash = handles splash screens
stcmd - no clue
stdout - can log a single service
suid - handles suid in services
syncron - starts one service at the time
up - starts a service when default is up.


As you can see it's quite many, and the api is getting quite big aswell
as we realized we need more and more stuff.
Some of the api is "watchers", stuff monitoring for example service
state/system state/a file descriptor, this is stuff easy to implement in
a unix socket (except from fd's, which wouldn't have to be), other
stuff, like chroot/suid would be very very hard I imagine.

But one thing I'd really like is some way of catching all output from
init, which would probably cause a lot of overhead running through unix
sockets? hm, maybe not, in either case it's one thing I kinda miss in
initng, as it'd be nice to run X up as soon as possible, and show the
boot events in X.