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 > > You can use /dev, which means it's accessable from very early in the boot, initng does this and it works well. Also, are we sure this needs a writable filesystem? I think if the socket exists it might not, I can't really remember ;)
>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... > > I have a bit of experience here, as initng has been trying out a few here, fifo's were horrible and unix sockets worked very well, and we can solve issues here either with initramfs on boot or by waiting until /dev is mounted (which by initng is after the first script is launched). How much do we want to support remotly though? Do we want a plugin api or a comunication api? I imagine a comunication api would end up being considerably more advanced and a lot harder to implement, but that could be because I'm used to working with plugins ;) >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 >[email protected] >http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel > > > _______________________________________________ initscripts-ng-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
