From: "Michael S. Tsirkin" <mst@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: aliguori@us.ibm.com, Marcel Apfelbaum <marcel.a@redhat.com>,
qemu-devel@nongnu.org, pbonzini@redhat.com, afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH v4 0/3] qemu-help: improve -device command line help
Date: Tue, 13 Aug 2013 13:36:06 +0300 [thread overview]
Message-ID: <20130813103606.GE25004@redhat.com> (raw)
In-Reply-To: <87mwol29rg.fsf@blackfin.pond.sub.org>
On Tue, Aug 13, 2013 at 11:57:39AM +0200, Markus Armbruster wrote:
> This isn't patch review, just a couple of observations and questions.
>
> Current use of categories, please correct misunderstandings:
>
> * A device can have multiple categories. Most (all?) devices currently
> have exactly one.
>
> * -device help shows categories, like this:
>
> name "NAME", bus "BUS", categories "CAT1" "CAT2"...
>
> * -device help is sorted by category
>
> * -device help shows the device once per category. If the device has no
> categories, it's not shown at all.
>
> Should we require devices to have at least one category?
I think yes - there's a misc category so this shouldn't be a problem.
> Eric, does libvirt still parse -device help? If yes, can it cope with
> the addition of "categories ..."?
>
> A possibly better way to group help by category: instead of adding
> categories to each line, add category headlines, like this:
>
> Controller/Bridge/Hub devices:
> name "NAME", bus "BUS"...
> ...
> USB devices:
> name "NAME", bus "BUS"...
> ...
> Storage devices:
> ...
>
> This way, showing devices with multiple categories once per category
> actually makes sense.
Yes, that's a good next step I think. Also, if we do hierarchical
layout, how about we actually lay it out in a sane readable way?
name NAME
bus BUS
...
>
> DEVICE_CATEGORY_STORAGE comprises both storage controller devices
> (providing storage buses such as IDE, SCSI) and storage devices
> (plugging into such buses). Some of our devices (*-fdc, virtio-blk)
> integrate both in one device model[*].
Let's create two categories and set them for these.
> DEVICE_CATEGORY_USB comprises *only* host controller devices (providing
> USB bus(es)), *not* USB devices (plugging into USB bus).
This sounds sane - this is their function.
> These are
> categorized by function instead:
>
> * DEVICE_CATEGORY_BRIDGE: usb-host, usb-hub
>
> * DEVICE_CATEGORY_STORAGE: usb-bot, usb-uas, usb-storage
>
> * DEVICE_CATEGORY_NETWORK: usb-bt-dongle, usb-net
>
> * DEVICE_CATEGORY_INPUT: usb-kbd, usb-ccid, usb-wacom-tablet,
> usb-braille, usb-mouse, usb-serial
>
> * DEVICE_CATEGORY_SOUND: usb-audio
>
> * DEVICE_CATEGORY_MISC: usb-tablet, usb-redir
>
> Should they additionally be DEVICE_CATEGORY_USB?
I think not - bus info is supplied by the bus field already.
What device provides is what is missing and category is
trying to fill in.
> Why do we have DEVICE_CATEGORY_USB, but no categories for other buses,
> like PCI or ISA? Devices providing such buses are
> DEVICE_CATEGORY_BRIDGE. Why is USB different?
> Why is usb-host DEVICE_CATEGORY_BRIDGE?
I agree this is weird. I'd say let's create _PCI, _ISA and _I2C
and get rid of _BRIDGE.
>
> Why is usb-tablet DEVICE_CATEGORY_MISC, but usb-wacom-tablet
> DEVICE_CATEGORY_INPUT?
>
> DEVICE_CATEGORY_INPUT is weird. Some devices in that category are truly
> about input (usb-mouse, usb-kbd), others are at least as often used for
> output (serial devices, PIOs)...
Serial is common enough to have a category of its own.
Suggestions for a good category for PIOs etc?
Maybe MISC is a good fit for these.
> The difference between DEVICE_CATEGORY_INPUT and DEVICE_CATEGORY_MISC
> seems unclear (see usb-tablet vs. usb-wacom-tablet above).
I think MISC should be the last resort.
>
>
> [*] I hate that.
next prev parent reply other threads:[~2013-08-13 10:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-29 14:17 [Qemu-devel] [PATCH v4 0/3] qemu-help: improve -device command line help Marcel Apfelbaum
2013-07-29 14:17 ` [Qemu-devel] [PATCH v4 1/3] hw: import bitmap operations in qdev-core header Marcel Apfelbaum
2013-07-29 14:17 ` [Qemu-devel] [PATCH v4 2/3] qemu-help: Sort devices by logical functionality Marcel Apfelbaum
2013-07-29 18:11 ` Michael S. Tsirkin
2013-07-29 14:17 ` [Qemu-devel] [PATCH v4 3/3] devices: Associate devices to their logical category Marcel Apfelbaum
2013-07-29 18:11 ` [Qemu-devel] [PATCH v4 0/3] qemu-help: improve -device command line help Michael S. Tsirkin
2013-07-29 20:23 ` Anthony Liguori
2013-08-13 9:57 ` Markus Armbruster
2013-08-13 10:36 ` Michael S. Tsirkin [this message]
2013-08-13 12:06 ` Eric Blake
2013-08-21 7:47 ` Marcel Apfelbaum
2013-08-21 9:23 ` Markus Armbruster
2013-08-21 10:42 ` Marcel Apfelbaum
2013-08-21 12:38 ` Michael S. Tsirkin
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=20130813103606.GE25004@redhat.com \
--to=mst@redhat.com \
--cc=afaerber@suse.de \
--cc=aliguori@us.ibm.com \
--cc=armbru@redhat.com \
--cc=marcel.a@redhat.com \
--cc=pbonzini@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).