[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: |
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?
[Qemu-devel] Re: [PATCH v2 1/2] early set current_machine, Anthony Liguori, 2010/06/03