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

["Michael S. Tsirkin" <mst@redhat.com>]

On Sun, Jul 21, 2013 at 02:09:20PM +0200, Andreas Färber wrote:
> 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.

This is not a problem with implementation - that can be added on top.
I think HMP is a good start, that's where we have a real
pain point now, with basically no documentation, and it's
a less risky change with no compatibility commitments.

> For another, this adds a third tree overlay over devices:

Exactly. And that's by design since this information
is currently missing.

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

This idea can't support multi-category devices.
To me, duplication seems minimal.

On the other hand plain C is much more readable than makefile based tricks.

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

What you suggest is mostly already available in the form of
"bus" field in -device help output.

But this misses the whole point which is to help users find
devices implementing a specific functionality.

> 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

As long as there are no plans to support multiple inheritance in QOM,
this does not seem feasible.

If category information does become available in QOM, it will be easy
to rip out an extra field, so I don't think we need to keep out
help text in the current messed-up state indefinitely until it's
available.

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