Proposal: "debug" branch for the kernel

[Clinton Ebadi]

Werner Almesberger <werner at openmoko.org> writes:

> So I think what we should have is just a general state machine.
> That's flexible, easy to understand while it's simple, but still
> manageable when (not if ;-) it gets larger and more complex.
>
> It's also straightforward to translate layered state machines into
> a single one, if that need should ever arise.
>
> Another issue is the configuration language. When I have to solve
> a non-trivial problem, I usually ask myself "in what language could
> I express this elegantly ?". The answer to this shouldn't be  "C",
> "Python", or such, but rather a new language - designed for the task.
>
> If I notice that this new language really just does what an exiting
> one does well already, I just pick that one. But if the difference in
> degree of abstraction is large enough, I then make this new language
> the centerpiece of the design, and work up and down from there.
>
> I also tend to make sure that my languages are valid CPP input. That
> way, I can make things optional and work with macros, keeping my own
> language compact while still having powerful instruments to fight
> redundancy. Redundancy is, of course, my number one enemy, even
> before complexity. (*)

Smells like Lisp to me ;-)

The Daemon Managing Daemon[1] sort of does this. Alas, like all things
Hurd related, it looks very unmaintained and potentially (a cursory
test shows that it at least starts with 1.8 and git head) broken
against the latest Guile. And it is Guile so I suspect almost everyone
would hate it with an undying passion.

In DMD you define various runstates and services and have full control
over what is running via arbitrary combinations. You just drop a
command into its command socket (each service type can have an
arbitrary set of commands and services are defined via GOOPS classes
so you can do inheritance of commands) and it reconfigures the
system. New commands and system states can be defined in Scheme fairly
easily, and, being Scheme, it is more or less infinitely
existensible. It also uses a sane dependency system allowing it to
start independent components of the dependency graph in parallel (it's
been a while since I used DMD and so I forget whether it implements
this yet).

The really killer feature of course is the existensiblity via GOOPS
classes. Need a new 'runlevel' for airplane mode? Ok just define an
<airplane-mode> class and have it invoke services to shutdown GSM but
leave the rest of the system running; rather than having separate
daemons to initialize the system, to figure out what to stop on
suspend, to decide what device states need to be restored on resume,
to reconfigure the system for various states (e.g. airplane mode),
etc. there could be a single daemon managing all of them. All with the
flexibility of the Scheme (and old style `defmacro') macro system for
defining new DSLs for each of these subtasks (or potentially the
guile-library LALR module if non-sexp syntax is desired). Why have a
dozen daemons for a dozen somewhat similar tasks when you could have
one very flexible daemon for all of them? Farewell Redundancy *and*
Complexity and Hackish 1970s Init.

[1] http://directory.fsf.org/project/DMD/

-- 
Jessie: i thought your beard took the oxygen from the air and made it
        breathable for you