[Top][All Lists]

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

Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options

From: Markus Armbruster
Subject: Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options
Date: Thu, 07 Jun 2012 12:05:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

[cc: Dan to give him a chance to correct whatever underinformed nonsense
I might spout on libvirt]

Anthony Liguori <address@hidden> writes:

> On 06/07/2012 04:07 PM, Markus Armbruster wrote:
>> Anthony Liguori<address@hidden>  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.
> I think we have a different world view.
> I see 'qemu -machine foo' as creating some useful variant of 'foo'
> where 'foo' is a user visible concept like a PC, or a Beagle board, or
> a pSeries machine.
> If I went to Fry's an bought a PC, I'd expect to plug it in and for it
> to have everything I needed including USB.  If I'm cheap, maybe I want
> to lower the amount of RAM or reuse the VGA card I bought for
> Christmas to play Halo 15 with.
> I see machine options as a way to customize that PC.  Maybe I want to
> not include USB by default because I have some religious opposition to
> protocols that start with 'U'.
> Machine configuration options are the QEMU equivalent of the drop-down
> box where you select options when buying a laptop from Dell.
> '-nodefault' is like buying a PC out of a back of an unmarked van on a
> street corner.  God knows why it doesn't come with a serial port.
> Maybe that got broken while it was being stolen during a break in.
> Maybe it's got a VGA card but no disk controller because they sold the
> VGA card separately to make more money.

Entertaining imagery, but hardly a fair description of what -nodefaults
does.  -nodefaults is shorthand for "deselect everything in the drop
down box".  God knows why the drop down box has "disable serial port",
but it has.  God knows why the drop down box is so ugly and hard to use,
but it is.  Maybe we could happily do without the "deselect everything"
shorthand if the drop down box didn't suck so much, but it does.

> What libvirt really wants is to buy the *components* of a PC and build
> it from scratch.  They want to separately buy the mother board, the
> case, the graphics adapter, etc.  libvirt is the 16-year kid with
> pimples who spends Saturday night reading Newegg to find the new 750W
> power supply that's water cooled and tricked out with LEDs that I'm
> sure we all were at some point in our lives.

Again, entertaining imagery, but hardly a fair description of libvirt's

Things libvirt really wants:

* Stable names.  Many default devices don't get any.  Yes, we can fix
  that.  Until we do, the only way to get names is to suppress default
  devices and define them yourself.

* Expose QEMU features to its users.  In particular, if a device is
  optional in QEMU, libvirt wants to be able to control its "enable"
  bit.  As it is, -nodefaults is the only way that works the same for
  all default devices, and for some of them it's the only way that works
  at all.

> So I guess this is the long way of saying, let's not provide an
> interface from the back of an unmarked van.  Let's either provide a
> nice drop-down menu (-machine options) or provide a Newegg catalog
> that has every component in it.

I doubt we're actually disagreeing on anything substantial.

I'm sure we can improve on -nodefaults.  But let's not break its core
feature "disable all default devices that can be disabled" before we
actually provide a working alternative that satisfies the needs of its

reply via email to

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