[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: Tue, 12 Jun 2012 10:06:59 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> On 06/07/2012 06:05 PM, Markus Armbruster wrote:
>> [cc: Dan to give him a chance to correct whatever underinformed nonsense
>> I might spout on libvirt]
> Don't see Dan on CC so I'll add him...
>> Anthony Liguori<address@hidden>  writes:
>>> 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
>> motivation.
>> 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.
> I'll resist the urge to extend the analogy and just keep it simple.
> -machine is an objectively better interface for achieving the above.  Here's 
> why:

Note that I'm not arguing against -machine at all.  Only against
breaking -nodefault before its replacement is fully ready.

> 1) There is no way to determine when the semantics of -nodefault
> changes and no clear compatibility statement.
>  a) Would it be okay to make -nodefault suppress the the IDE
> controller for -M 
> pc at this point in time?

Incompatible change, thus requires a new machine type.

Since pc is just an alias for the latest pc-X.Y, one could argue that
users of pc need to be prepared for incompatible changes when pc points
to a new pc-X.Y, and therefore we could make the change in a new pc-X.Y.
I'd think twice about that.  At least.

>  b) Would it be okay to add USB by default and make -nodefault disable it?

Same thing: new machine type.

>  c) How does libvirt figure out when any of the above happens?

It uses the machine types it knows, and gets updated for new machine
types.  Best it can do given what we offer it now.

> 2) There is no way to figure out what -nodefault does without deep
> code inspection since it depends on each machine.

Could be regarded as a documentation bug.

Other command line options have similar, although less serious issues.
For instance, -serial can

* replace the machine's default serial device, or

* add a new serial device (exact type depends on machine), or

* do nothing at all

depending on the machine.  Code inspection or experiment required to
figure it out.

That said, I'm all for simple options with documented or easily
discoverable semantics.

> 3) -machine is both discoverable (you can see when new options are
> added), but also has the ability to support compatibility.  If we
> decide to add usb by default, libvirt can see that 'usb' has been
> added and disable it.  If we decide to make the IDE device hide-able,
> we can add an 'ide' option and default it to True.

How should libvirt decide that the new and unknown option "usb" needs to
be disabled for backward compatibility, but the equally new and unknown
option "ide" needs to be left enabled?

> 4) The -machine option supports sane backporting.  Since you can
> discover individual features of -machine, libvirt can deal with any
> combination of features being available.
> We didn't have -machine when -nodefaults was introduces.  Now that we
> do, we should make good use of it.

Once again, that I'm not arguing against -machine at all.  Only against
breaking -nodefault before its replacement is fully ready.

> Regards,
> Anthony Liguori
>>> 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
>> users.

reply via email to

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