From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59214) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c96Hf-0002nj-Ra for qemu-devel@nongnu.org; Tue, 22 Nov 2016 03:18:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c96Ha-0007Fe-Tz for qemu-devel@nongnu.org; Tue, 22 Nov 2016 03:18:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33146) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c96Ha-0007Ef-NY for qemu-devel@nongnu.org; Tue, 22 Nov 2016 03:18:26 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E3EEE61BBA for ; Tue, 22 Nov 2016 08:18:24 +0000 (UTC) References: <1479777133-23567-1-git-send-email-ehabkost@redhat.com> From: David Hildenbrand Message-ID: <80ff3d9b-5a3a-f064-c72b-0152e18d6ef3@redhat.com> Date: Tue, 22 Nov 2016 09:18:21 +0100 MIME-Version: 1.0 In-Reply-To: <1479777133-23567-1-git-send-email-ehabkost@redhat.com> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , qemu-devel@nongnu.org, Markus Armbruster , Marcel Apfelbaum , "Michael S. Tsirkin" Cc: libvir-list@redhat.com, Laine Stump > > 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