Re: [Qemu-devel] [PATCH 1/1] Support default interface types per QEMUMachine

[Andreas Färber]

Am 26.04.2012 20:10, schrieb Anthony Liguori:
>> Not so long ago you told me that the whole machine should go into
>> configuration files... If we do start drilling up QEMUMachine now, we
>> should seriously QOM'ify it for 1.2.
> 
> QOM represents logic objects.  It's a data model and when we model
> hardware, we can model something concrete (because hardware for the most
> part has a physical implementation).
> 
> Machines are entirely a QEMU concept.  There's logic in the machines
> that will never be able to be expressed in a config file.  Machines make
> decisions about things like what the best NIC to use is.  There's no way
> to model "the best nic" in QOM.
> 
> Now a machine should *only* do things that can be done through a config
> file. IOW, the output of the machine function could be a config file
> that is then used to do a bunch of QOM operations.  That's perhaps a
> simplification but you get the general idea hopefully.
> 
> But I don't see a tremendous amount of value in just making QEMUMachine
> an Object.  I can certainly be convinced otherwise, but it's not obvious
> to me how it would be helpful.

My job has long included looking at code and spotting recurring
patterns: I see that we have multiple mechanisms for object registration
and creation. In your mind you still have devices and draw a line
between what exists physically and just in QEMU; I see types and a
recently unified type_init() and got taught that an object is an
artificial abstraction concept (and that reality and language are both
constructs of culture fwiw - K. P. Hansen, 1993).

The machine registration is pretty similar to QOM but is lacking
features such as inheritance and composition, so just like someone was
QOM'ifying net devices and there being talk of doing so for block
devices - which I fully agree are not devices in the qdev sense - I'm
thinking our infrastructure should be solicited to use the same object
infrastructure consistently.
Therefore it's not obvious to me why we'd introduce a dummy /machine
container object and at the same time oppose reworking it to use the QOM
infrastructure and start reworking the old-style QEMUMachine. Either
it's so bad and superfluous that we don't touch it at all until the
heavenly config file arrives or we're pragmatic and update the code
along the way. So far I'm not seeing where exactly the journey is going
to end so I'm looking at what we have today.

The reason why the machine is important to consider early is timing:
Since we've started adding child<> properties to the machine (e.g.
"unassigned"), we'd need to take care that the creation order does not
add childs to the default machine before the actual machine is selected
and instantiated.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg