Re: [Qemu-devel] [PATCH 3/4] Add -defaults option to allow default devices to be overridden

[Anthony Liguori <aliguori@linux.vnet.ibm.com>]

On 01/22/2010 04:15 AM, Markus Armbruster wrote:
> Anthony Liguori<aliguori@us.ibm.com>  writes:
>
>    
>> This option can be used to toggle whether each default device is enabled or
>> disabled.  For character devices, the default backend can also be overridden.
>>
>> For devices, we'll have to take a different approach to changing the defaults
>> which will be covered in the next patch.
>>
>> N.B. I took special care with -nographic.  Now -nographic pretty clearly acts
>> as a mechanism to override the default backend devices.
>>
>> Signed-off-by: Anthony Liguori<aliguori@us.ibm.com>
>> ---
>>   qemu-config.c   |   45 +++++++++++++++++++++++++++++++++
>>   qemu-config.h   |    1 +
>>   qemu-options.hx |    7 +++++
>>   vl.c            |   75 +++++++++++++++++++++++++++++++++++++++++--------------
>>   4 files changed, 109 insertions(+), 19 deletions(-)
>>
>> diff --git a/qemu-config.c b/qemu-config.c
>> index c3203c8..82ca399 100644
>> --- a/qemu-config.c
>> +++ b/qemu-config.c
>> @@ -242,6 +242,50 @@ QemuOptsList qemu_mon_opts = {
>>       },
>>   };
>>
>> +QemuOptsList qemu_default_opts = {
>> +    .name = "default",
>> +    .head = QTAILQ_HEAD_INITIALIZER(qemu_default_opts.head),
>> +    .desc = {
>> +        {
>> +            .name = "serial",
>> +            .type = QEMU_OPT_STRING,
>> +        },
>>      
> [...]
>    
>> diff --git a/qemu-options.hx b/qemu-options.hx
>> index 57f453d..e81ecb5 100644
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -1919,6 +1919,13 @@ STEXI
>>   Don't create default devices.
>>   ETEXI
>>
>> +DEF("default", HAS_ARG, QEMU_OPTION_default, \
>> +    "-default arg    specify default devices\n")
>>      
> Isn't this too terse?
>    

Yes.  Thanks for pointing that out.

>> +STEXI
>> +@item -defaults
>> +Override builtin default devices
>> +ETEXI
>>      
> This *is* too terse :)
>
> Oh, and it's -default (sans 's').  Same typo in subject.
>
> While we're talking about naming: isn't -default a bit too generic a
> name for something that manipulates devices?  Not sure we care, as
> -nodefaults is much worse, already.
>    

Absolutely.  I'm going to split out the config loading bits because they 
should be easy to commit.  How to best handle defaults could use some 
more thought.  I think this is a key bit of functionality to get right 
though because it solves a whole class of problems relating to upstream 
policy vs. downstream policy.

I very much like the idea of having a qdev property 'default' to signify 
that this is a default device.  It means we could easily allow a user to 
universally enable usb devices, etc without baking a default_usb concept 
into qemu.  Ideally, we could eliminate the whole default mess we have 
today by doing this, provided that we can implement the right semantics.

Today, those semantics are, if we specify any device of the same 
"class", do not load default devices of that class.  It's unclear how to 
specify the concept of a "class" though.  I know Gerd brought this up 
ages ago and both Paul and I were very opposed to it but I certainly 
appreciate the fact that it would simplify default device handling.

It's definitely clear that each device needs to be able to be part of 
multiple default-class's.  We could potentially introduce a qdev 
property and label every device with a class array but that's a lot of 
ugliness just to support defaults.  I still would prefer that there was 
a more discoverable way to determine the class of a device as opposed to 
explicitly labelling it.

If we need to do class tagging, I guess it's not the end of the world...

Regards,

Anthony Liguori

> [...]
>