From: David Hildenbrand <david@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>,
qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
Marcel Apfelbaum <marcel@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Cc: libvir-list@redhat.com, Laine Stump <laine@redhat.com>
Subject: Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
Date: Tue, 22 Nov 2016 09:18:21 +0100 [thread overview]
Message-ID: <80ff3d9b-5a3a-f064-c72b-0152e18d6ef3@redhat.com> (raw)
In-Reply-To: <1479777133-23567-1-git-send-email-ehabkost@redhat.com>
>
> Considered alternatives
> =======================
>
> Indirect mapping (machine => bus => device)
> -------------------------------------------
>
> This RFC implements a mechanism to implement ax
> machine-type => supported-device-types
> mapping. An alternative solution I considered was to expose an
> indirect mapping:
> machine-type => default-bus-types
> followed by
> bus-type => supported-device-types.
>
> But exposing only the resulting supported device-types list
> imposes less restrictions on how the device and bus type
> hierarchy is implemented inside QEMU. There's still a
> machine-type => bus-type => device-type
> mapping implemented internally, but it is an implementation
> detail on the current version, and not part of the
> externally-visible interface.
>
> The Implementation
> ==================
>
> This add a new field to MachineClass: default_bus_types, and a
> new field to BusClass: supported_device_type.
Is it possible to modify a machine (setting some properties e.g. on the
command line), that suddenly more devices are supported? Something like
enabling an additional bus? (I assume so, because it is called "default
bus types" :) )
If so, the indirect mapping could be of more benefit in the long run.
Thinking about my machine at home:
I just care about the available buses. If my machine doesn't have USB,
but PCI, I can buy a USB PCI card and make it support USB. Then I can
happily plug in USB devices. So the "default" state might at least
no longer be sufficient when wanting to plug in a USB fan on a hot
summer day ;) .
But, with the indirect mapping, I guess we would need yet another qmp
command ...
--
David
next prev parent reply other threads:[~2016-11-22 8:18 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
2016-11-22 1:11 ` [Qemu-devel] [RFC 01/15] qemu.py: Make logging optional Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 02/15] qtest.py: Support QTEST_LOG environment variable Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 03/15] qtest.py: make logging optional Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 04/15] qtest.py: Make 'binary' parameter optional Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 05/15] tests: Add rules to non-gtester qtest test cases Eduardo Habkost
2016-11-22 13:34 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 06/15] qdev: Add device_type field to BusClass Eduardo Habkost
2016-11-24 16:48 ` Cornelia Huck
2016-11-24 17:37 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 07/15] machine: Add MachineClass::default_buses field Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 08/15] qmp: Add 'supported-device-types' field to 'query-machines' Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 09/15] pci: Introduce INTERFACE_PCIE_DEVICE interface name Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 10/15] pc: Initialize default bus lists Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 11/15] s390x: " Eduardo Habkost
2016-12-05 15:24 ` David Hildenbrand
2016-12-05 16:03 ` Cornelia Huck
2016-12-05 16:38 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 12/15] arm: " Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 13/15] mips: " Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 14/15] ppc: " Eduardo Habkost
2016-11-23 3:42 ` Alexey Kardashevskiy
2016-11-22 1:12 ` [Qemu-devel] [RFC 15/15] qdev: Add device_class_set_bus_type() function Eduardo Habkost
2016-11-22 1:34 ` [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' no-reply
2016-11-22 1:36 ` no-reply
2016-11-22 8:18 ` David Hildenbrand [this message]
2016-11-22 13:09 ` Eduardo Habkost
2016-11-22 22:34 ` Eduardo Habkost
2016-11-23 17:10 ` [Qemu-devel] -nodefaults and available buses (was Re: [RFC 00/15] qmp: Report supported device types on 'query-machines') Eduardo Habkost
2016-11-24 1:51 ` David Gibson
2016-11-24 16:30 ` Cornelia Huck
2016-11-24 17:42 ` Eduardo Habkost
2016-11-24 13:39 ` Markus Armbruster
2016-11-23 16:43 ` [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Marcel Apfelbaum
2016-11-23 17:35 ` Eduardo Habkost
2016-11-24 9:34 ` Marcel Apfelbaum
2016-11-24 13:34 ` Markus Armbruster
2016-11-24 14:12 ` Eduardo Habkost
2016-11-24 14:55 ` Markus Armbruster
2016-11-24 14:22 ` Marcel Apfelbaum
2016-11-24 15:41 ` Markus Armbruster
2016-11-24 16:31 ` Marcel Apfelbaum
2016-11-25 8:03 ` Markus Armbruster
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=80ff3d9b-5a3a-f064-c72b-0152e18d6ef3@redhat.com \
--to=david@redhat.com \
--cc=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=laine@redhat.com \
--cc=libvir-list@redhat.com \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--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).