Re: [Qemu-devel] [RFC] Machine description as data

[Markus Armbruster <armbru-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

Paul Brook <paul-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org> writes:

>> > The machines I care for come with many optional and configurable parts.
>> > We select the basic machine type with command line option -M, and
>> > configure the rest with more command line options.  I figure we want to
>> > keep supporting these options, at least for a while.
>> >
>> > I believe the best way to deal with that is start with a basic tree
>> > selected by -M, then modify it according to the other options.  So,
>> > there's a fair amount of configuration tree mutation.
>>
>> Yeah, you're probably right.  Although, in some cases the amount of
>> complex tree mutation can be cut down by thinking about things in the
>> right order.  For example if you have a bunch of optional devices,
>> rather than adding them one by one (with all the required properties)
>> to the skeleton tree, you can instead have the skeleton tree be the
>> all-bells-and-whistles variant then delete the subtrees that aren't
>> present.  libfdt even has a function to replace subtrees with nops
>> instead of eliding them, which means the offsets of other nodes won't
>> change.
>
> I'm not so sure this is a vital feature. The current commandline options only 
> provide the absolute bare minimum mutation for a basic PC machine, and don't 
> even do that particularly well. I'm inclined to say we should punt 
> significant machine config modification/generation to an external tool.

I'm not exactly in love with the currrent command line myself.  It's
just that I'm trying to make improvements in modest steps with minimal
disruption.  I'd rather not start with throwing out the command line.

If the need for tree manipulation goes away, we can still ditch the
separate internal tree structure and go all FDT.  My prototype already
has a converter to and from FDTs, to demonstrate that the internal tree
is just as treeish as an FDT.