[Top][All Lists]
[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
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] Re: [PATCH v2 1/2] early set current_machine, Anthony Liguori, 2010/06/03