On Thu, Oct 23, 2014 at 6:45 PM, Jonathan de Boyne Pollard < j.deboynepollard-newsgro...@ntlworld.com> wrote:
> Lee Winter: > >> One key component of an effective startup process is dependency >> > > handling. So why not look for one of the best as a model? I > > suggest DJB's redo system. It is excruciatingly simple. But very > > effective. And it is the opposite of monolithic. > > Is "practically nonexistent" the opposite of monolithic, now? (-: He > never actually published it, you know (although a few of his other > unfinished works that did get published contain glimpses in their build > systems). The task of constructing and publishing working redo toolsets > was left to Alan Grosskurth, Avery Pennarun, and some other bloke. > There are more than three implementations of what little DJB did publish, each with its own strengths and weaknesses. But building software and booting (including careful shutdown) are two quite separate goals. I suspect you interpreted my suggestion a bit too literally. redo is a useful tool that can have a use in system initialization. Someone > asked me an interesting question about /etc/rc.conf.local in FreeNAS > recently and I came up with an interesting answer that made use of redo > which I have to write up at some point. But it's another tool in a good > toolbox, not the whole of the toolbox. Nor is it necessarily the starting > point for everything that has the word "dependency" somewhere in its > description. I can think of three things in the various implementations of > redo that will interact quite poorly with the notion of repeatably starting > up daemons with controlled initial process states and dropped privileges: > maintaining database and job control access, alternative routes, and what > the process tree ends up looking like. And that's skipping over the whole > notion of shutdown. There are ways to marry service dependencies with the > the-filesystem-is-the-database paradigm, but one doesn't really start here > to reach them. > DJB's design for redo is not aimed at an init tool. It is aimed at a make tool. It might be possible to adapt a make tool into an init tool, but that does not sound to me like it would be fun. The missing concept is a replacement for timestamp sequencing as used by make et al with a set of events that mean approximately "ready". And initing requires a systematic approach to determining readiness for every step of the boot process. I don't think timestamps will cut it. We need a different boolean predicate. And I agree that it has to be bidirectional in an edge-triggered sense. > Maybe Alan Grosskurth, Avery Pennarun, or that other bloke have written > some tools for system and daemon management. > It's possible. I do not track those implementations. I did study redo intensively as part of a better build search about a year ago. There were two finalists in my search, of which redo was one. But IMHO redo has too much human element to be reliable for large software development projects. But with redo it is _extremely_ easy to determine what is going on and just as easy to customize. Those are both properties that I also value for system software. Lee Winter Nashua, New Hampshire United States of America
