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
>
>
>
next prev parent 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).