[Qemu-devel] Re: [PATCH v2 2/2] basic machine opts framework

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

Glauber Costa wrote:
> On Wed, Jun 02, 2010 at 09:15:10AM +0200, Jan Kiszka wrote:
>>>  
>>> +QemuOptsList qemu_machine_opts = {
>>> +    .name = "M",
>>> +    .head = QTAILQ_HEAD_INITIALIZER(qemu_machine_opts.head),
>>> +    .desc = {
>>> +        {
>>> +            .name = "mach",
>>> +            .type = QEMU_OPT_STRING,
>>> +        },{
>>> +            .name = "irqchip",
>>> +            .type = QEMU_OPT_STRING,
>>> +        },
>> Can't we make the concrete machine define what options it needs? Pushing
>> this into the generic code may soon end up in a bunch of very special
>> switches that are unused on most machines or even have no meaning for them.
>>
>> Also, I would suggest to introduce the generic part first, and then add
>> first users like the x86 irqchip.
> Yeah, in general, I do agree with you.
> 
> Me and anthony talked about it for a while some time ago, and more or less
> concluded that it could be possible to avoid that, putting a little think
> which options to add.
> 
> the "irqchip" option, if you note, is not x86-specific, in any case.
> Any machine has an irqchip.

...but the majority has no choice among different models. This option
simply makes only sense for x86 now and in the foreseeable future.

> The first idea was to use something like
> "apic=in_kernel|userspace" which would be, that, very x86-centric.
> 
> So, since letting machines define their own options adds complexity,
> my take would be to add those common options, and add infrastructure
> for machine-specific options when we see something that makes it
> unavoidable.
> 
> What do you think? 
> 

I have no general concerns if you document irqchip as a x86-only machine
option without effect on other machines and you promise to clean this up
once done with in-kernel irqchip support (which is clearly more
important). But the current design should not stay that way for a longer
period to avoid what I sketched above.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]