Re: Redesign of QEMU startup & initial configuration

[Markus Armbruster]

Damien Hedde <damien.hedde@greensocs.com> writes:


[...]

>> Painted with a big brush, there are two kinds of code in hw/: actual
>> device emulation, and "wiring".  Both in C, and sometimes in the same .c
>> file.
>> 
>> Doing the "wiring" in configuration instead is less powerful (no longer
>> Turing complete[2]), but easier to reason about, maintain and change.
>> Change is possible even in the field.  The obvious separation between
>> emulation and wiring is a nice bonus.
>> 
>> The wiring C code supports something not unlike templating: we have a
>> number of configuration knobs that deposit something for the wiring C
>> code to pick up.
>> 
>> It's rather limited, though: the "variables" are fixed at compile time.
>> 
>> Aside: the handling of variables that doesn't get substituted is wildly
>> inconsistent.
>> 
>> Perhaps doing wiring in configuration reduces the maintenance burden to
>> a degree where we can mitigate the "defaults gone bad, but no want
>> change" issue by offering additional, better things instead of changing
>> existing, bad things.  I don't know.
>
> We should be careful with config files, because the configuration
> parser can become a real mess.

Oh yes.

>                                There are 2 kinds of config files:
>
> 1. Imperative: an equivalent of QAPI/QMP command script. (eg like CLI
> config files Markus proposed). These are easy to handle because they 
> follow the QMP flow. We do one command after the other, the ordering
> of tasks is clear.
>
> 2. Descriptive: A description of the configuration where we describe
> the components and the wiring. This can be really complicated because
> we easily end up with ordering/determinism issues when instantiating
> them afterwards. For example the  configuration parser may have to
> solve : Which device do I create first ? I don't think a configuration
> parser should have to solve such issues, but I'm not sure if we can
> avoid it.

Actual instantiation necessarily happens in some order[*].

An imperative configuration dictates the order.

A descriptive configuration leaves it to some planner software.

Any descriptive configuration can therefore be transformed into an
imperative one.  *Unless* the planner *also* breaks up components into
smaller ones that aren't accessible in the imperative configuration.

Example: say the configuration specifies a device and its connections as
a unit.  Say we have two devices A and B, where A has a connection A->B,
and B a connection B->A.  A sufficiently smart planner can then create
A, B, A->B, B->A.  You can't express this imperatively unless connection
B->A can be specified separately from device A.

I propose to start stupid, i.e. with an imperative, low-level
configuration.  Then add smarts as we need them.


[*] Even if you instantiate stuff concurrently for some reason, there
should be at least some conceptual order.