All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Benjamin Herrenschmidt <benh@au1.ibm.com>,
	li zhang <zhlcindy@gmail.com>,
	qemu-devel@nongnu.org, zhlcindy@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options
Date: Thu, 07 Jun 2012 10:07:10 +0200	[thread overview]
Message-ID: <m3d35bv93l.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <4FD000B6.8060308@us.ibm.com> (Anthony Liguori's message of "Thu, 07 Jun 2012 09:15:34 +0800")

Anthony Liguori <aliguori@us.ibm.com> writes:

> On 06/07/2012 05:13 AM, Benjamin Herrenschmidt wrote:
>> On Wed, 2012-06-06 at 13:42 +0800, Anthony Liguori wrote:
>>> On 06/06/2012 11:31 AM, Benjamin Herrenschmidt wrote:
>>>> On Wed, 2012-06-06 at 10:52 +0800, li zhang wrote:
>>>>> Hi Anthony,
>>>>>
>>>>>
>>>>> Any comment on this?
>>>>
>>>> Allright, this is all quite confusing...
>>>>
>>>> He's what I think should happen:
>>>>
>>>> When no option is passed -at-all-, we should have vga std and usb ohci +
>>>> usb mouse + usb ps2.
>>>>
>>>> When -nodefault is passed, we should have none of the above.
>>>
>>> -nodefault is a pretty ugly hack.  I don't think there's any good reason to
>>> involve -nodefault into this discussion.
>>
>> Well, it's pretty fundamental to how libvirt does thing afaik...
>>
>> Take pseries, by "default" today it has a vscsi, a vterm etc.... but
>> with -nodefault, none of this so libvirt can create them manually.
>
> You misunderstand what I'm saying.
>
> -nodefault is a dumb option.  It's semantics are poorly defined
> because it depends on machine.  Further complicating those semantics
> by adding more magic for -M spapr just makes the situation worse.

Without -nodefaults, you get the machine the developers think most
people want.  Example: you may get a default serial device.  Whether you
get one and which one you get depends on the machine.

With -nodefaults, you get a variant of the same machine with those
optional devices omitted the developers think somebody might want to
suppress or define himself.

Both are "defined" the same way: you get what you get, and the
developers promise not to change it too much.

For some kinds of devices, there's magic to make user-defined devices
replace default devices.  Example: -serial and -device isa-serial
suppress the default serial device.

For some kinds of devices, there's a device-specific way to suppress
default devices.  Example: -serial none suppresses the default serial
device.  Counter-example: you can't suppress the default floppy
(frontend if the machine supports floppies, backend whether it does or
not) other than with -nodefaults.

The truly "poor" bit in -nodefaults is the name: I keep reading "node
faults" %-)

> I'm suggesting to make use of the -machine option to allow usb to be disabled.  So:
>
> qemu-system-ppc64 -machine type=spapr,usb=off
>
> libvirt can still happily name the usb controller whatever it wants.
> But the end result is a less magical command line.

The USB host controller is currently disabled by default on all
machines.  If we enable it by default (which I think is a good idea), we
may want to give users a way to suppress it.

Your proposed -M parameter usb is yet another device-specific way to
suppress default devices.  We got a few, one more won't kill us.  Much
better would be adding a device-independent way to suppress a default
device.

Adding default USB suppression without having -nodefaults cover it is
something new, though: -nodefaults no longer omits optional devices "the
developers think somebody might want to suppress or define himself".
Feels like reneging on what -nodefaults promised to do.  I'd recommend
to think twice about that.

  parent reply	other threads:[~2012-06-07  8:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-05  9:48 [Qemu-devel] [qemu-devel][RFC] Enable usb with default options li zhang
2012-06-06  2:52 ` li zhang
2012-06-06  3:31   ` Benjamin Herrenschmidt
2012-06-06  5:42     ` Anthony Liguori
2012-06-06  6:03       ` li zhang
2012-06-06 21:13       ` Benjamin Herrenschmidt
2012-06-07  1:15         ` Anthony Liguori
2012-06-07  3:00           ` Benjamin Herrenschmidt
2012-06-07  3:03             ` Anthony Liguori
2012-06-07  4:52             ` li zhang
2012-06-07  4:39           ` li zhang
2012-06-07  4:43             ` Anthony Liguori
2012-06-07  4:53               ` li zhang
2012-06-07  8:07           ` Markus Armbruster [this message]
2012-06-07  9:19             ` Anthony Liguori
2012-06-07 10:05               ` Markus Armbruster
2012-06-07 11:51                 ` Anthony Liguori
2012-06-12  8:06                   ` Markus Armbruster
2012-06-07  8:32         ` Hans de Goede
2012-06-07  8:40           ` Benjamin Herrenschmidt
2012-06-07  8:49             ` Paolo Bonzini
2012-06-07  8:52             ` Hans de Goede
2012-06-07  9:05               ` Gerd Hoffmann
2012-06-07  9:17                 ` Benjamin Herrenschmidt
2012-06-07  9:29                   ` Li Zhang
2012-06-07  9:16               ` Benjamin Herrenschmidt
2012-06-07  9:50                 ` Hans de Goede
2012-06-07 11:19                   ` Benjamin Herrenschmidt
2012-06-07 11:35                   ` Gerd Hoffmann
2012-06-07  8:54             ` Gerd Hoffmann
2012-06-06 22:14     ` Andreas Färber
  -- strict thread matches above, loose matches on Subject: below --
2012-06-05  7:19 Li Zhang

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=m3d35bv93l.fsf@blackfin.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=benh@au1.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=zhlcindy@gmail.com \
    --cc=zhlcindy@linux.vnet.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.