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