Re: [Qemu-devel] [PATCH 1/5] Re-factor nic model listing

[Anthony Liguori]

Jamie Lokier wrote:
> Paul Brook wrote:
>   
> Doesn't it make sense to add pci_nic_models _automatically_ to any
> board with a PCI interface, and have nic_models just for additional
> NICs which aren't implied by having a PCI interface?
>   

No, there's a more fundamental "wrongness" at work here that has to do 
with the QEMUMachine abstraction out-living its usefulness.

A machine is hierarchical by nature.  Attaching PCI NICS to the 
top-level of a machine definition is wrong because it violates this 
hierarchical property.  It doesn't matter who does it or how it happens.

What you really need is a data structure that represents the machine in 
a more natural way.  You could have a Machine description, that contains 
a reference to a PCI bus description or an ISA bus description, that 
then contained descriptions of PCI or ISA NICS.

The problem is, a simple struct like QEMUMachine can not represent this 
relationship in a natural way.  The real trick here is to find an 
incremental way to introduce this sort of modeling without forcing an 
all-at-once refactoring of QEMU.

A good start may be to swizzle the QEMUMachine definition to contain 
just a name and then a function pointer to initialize the machine type.  
The function pointer would initialize the machine type by setting 
properties of it (like maximum CPUs) and then it could add bus 
descriptions to it.  You would have to introduce a mechanism to describe 
buses, of course.  The bus description could then have it's own 
initialization function that added supported PCI devices descriptions to 
the bus.  If these devices were tagged with a variety of types (like 
NIC, storage controller, etc), then you could implement something like 
what Mark is proposing by taking the QEMUMachine definition and walking 
the structure to discover all the possible NICs.

The long term goal we want to get at is one where the QEMUMachine 
definition is built entirely from a text-file description.  Fabrice's 
config file patches that he posted a few months back give a good insight 
into what things should eventually look like.

Regards,

Anthony Liguori

> -- Jamie
>
>
>