qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/2] qemu-help: improve -device command line


From: Andreas Färber
Subject: Re: [Qemu-devel] [RFC PATCH 0/2] qemu-help: improve -device command line help
Date: Sun, 21 Jul 2013 14:09:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7

Hi,

Am 18.07.2013 10:27, schrieb Marcel Apfelbaum:
> Running qemu with "-device ?" option returns ~145 lines.
> It is hard to manage understanding the output.
> 
> Theses patches aim to partially solve the problem by dividing the devices
> into logical categories like "Network/Display/..." and sorting them by it.
> 
> Marcel Apfelbaum (2):
>   qemu-help: Sort devices by logical functionality
>   devices: Associate devices to their logical category

Sorry to jump on this discussion. I think the idea to structure devices
better does make sense. However I feel that the implementation is not ideal:

For one, this adds a new field and uses it only for command line output,
while not benefiting libvirt or other QMP users.

For another, this adds a third tree overlay over devices:
We have the QOM inheritance tree with classifications such as PCIDevice,
ISADevice, VirtioDevice, USBDevice, etc.
We have Paolo's hw/ directory restructuring, which uses scsi, intc,
timer, etc. sub-directories.
The proposed category system is different from the sub-directories
(e.g., scsi/ vs STORAGE) and is completely manual, i.e. double work.

So I wonder if it would be possible to define the category per
Makefile.objs (whether in hw/Makefile.objs or in hw/*/Makefile.objs).

Or whether we can just reuse the type hierarchy and sort per base class
for now - the result would be different from the proposed categories but
hopefully reproducible elsewhere (assuming the base type is exposed in
QMP). Anthony had in the past suggested to change our inheritance tree
so that PCIDevice becomes an interface and the base class would be
specific to the chipset, i.e. might end up similar to the proposed
categories. (Getting rid of the parent field assumptions is a large
prerequisite for changing inheritance.)

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]