qemu-devel
[Top][All Lists]
Advanced

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

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


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH v2 2/2] basic machine opts framework
Date: Thu, 03 Jun 2010 08:07:05 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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: signature.asc
Description: OpenPGP digital signature


reply via email to

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