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?