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: Glauber Costa
Subject: [Qemu-devel] Re: [PATCH v2 2/2] basic machine opts framework
Date: Wed, 2 Jun 2010 11:06:08 -0300
User-agent: Jack Bauer

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. 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? 




reply via email to

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