qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/5] Re-factor nic model listing
Date: Thu, 13 Nov 2008 20:49:02 -0600	[thread overview]
Message-ID: <491CE71E.6030901@codemonkey.ws> (raw)
In-Reply-To: <20081114023147.GF2055@shareable.org>

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
>
>
>   

  reply	other threads:[~2008-11-14  2:49 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-13 16:45 [Qemu-devel] [PATCH 0/5] Add "info capabilities" monitor command Mark McLoughlin
2008-11-13 16:45 ` [Qemu-devel] [PATCH 1/5] Re-factor nic model listing Mark McLoughlin
2008-11-13 16:46   ` [Qemu-devel] [PATCH 2/5] Add cpu_list() for any targets that don't already have it Mark McLoughlin
2008-11-13 16:46     ` [Qemu-devel] [PATCH 3/5] Rename xxx_cpu_list() to cpu_xxx_list() Mark McLoughlin
2008-11-13 16:46       ` [Qemu-devel] [PATCH 4/5] Add new cpu_names() function Mark McLoughlin
2008-11-13 16:46         ` [Qemu-devel] [PATCH 5/5] monitor: add "info capabilities" command Mark McLoughlin
2008-11-13 19:50           ` [Qemu-devel] " Anthony Liguori
2008-11-14 16:02             ` Mark McLoughlin
2008-11-14 10:07           ` [Qemu-devel] " Avi Kivity
2008-11-14 15:58             ` Mark McLoughlin
2008-11-16  7:17               ` Avi Kivity
2008-11-14 10:13           ` Daniel P. Berrange
2008-11-13 19:47         ` [Qemu-devel] Re: [PATCH 4/5] Add new cpu_names() function Anthony Liguori
2008-11-14 15:36           ` Mark McLoughlin
2008-11-13 18:35   ` [Qemu-devel] [PATCH 1/5] Re-factor nic model listing Paul Brook
2008-11-13 19:45     ` Anthony Liguori
2008-11-13 22:50       ` Paul Brook
2008-11-14  2:31         ` Jamie Lokier
2008-11-14  2:49           ` Anthony Liguori [this message]
2008-11-13 19:44   ` [Qemu-devel] " Anthony Liguori
2008-11-14 15:34     ` Mark McLoughlin
2008-11-13 17:49 ` [Qemu-devel] [PATCH 0/5] Add "info capabilities" monitor command Blue Swirl
2008-11-14  2:50   ` Jamie Lokier
2008-11-14 16:09     ` Mark McLoughlin
2008-11-14  3:28 ` [Qemu-devel] " Anthony Liguori
2008-11-14  3:51   ` Jamie Lokier
2008-11-14 15:56     ` Mark McLoughlin
2008-11-14 22:54       ` Jamie Lokier
2008-11-14 15:51   ` Mark McLoughlin
2008-11-14 22:52     ` Jamie Lokier
2008-11-14 10:16 ` [Qemu-devel] " Daniel P. Berrange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=491CE71E.6030901@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).