Proposal: "debug" branch for the kernel

[Werner Almesberger]

Jay Vaughan wrote:
> integrate these various levels in your stack in a way to suit the user.

I don't think "levels" are a good abstraction for what we need here.
You have a global state (suspend/resume), local device states (e.g.,
WLAN powered or not), and application states (e.g., in call or not).

Most of them are somehow dependent on each other, but they don't
naturally form levels. You could remove some states from your
picture by considering them sub-states within a level, but I think
that would only make the design more complex.

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. (*)

(*) A nice example of what happens if you don't have such tools, or
    don't use them, is our army of ALSA state files, all similar,
    but not the same.

- Werner