On Tue, Nov 13, 2012 at 12:51:43PM +0100, Andreas Färber wrote: > Am 12.11.2012 23:33, schrieb Eduardo Habkost: > > On Mon, Nov 12, 2012 at 10:18:29PM +0000, Peter Maydell wrote: > >> On 12 November 2012 22:16, Eduardo Habkost <ehabk...@redhat.com> wrote: > >>> On Sat, Apr 14, 2012 at 05:42:10PM +0100, Peter Maydell wrote: > >>>> +static const ARMCPUInfo arm_cpus[] = { > >>> [...] > >>>> + { .name = "any", .initfn = arm_any_initfn }, > >>>> +}; > >>>> + > >>> > >>> Do we really want to use "any" as the class name? > >> > >> Probably not, since it would make it tricky to (in some future > >> utopia) have a QEMU which supported more than one CPU architecture > >> in the same binary if they all wanted to use "any"... > > > > In that case, "cpu-any" wouldn't work, either. What about > > "<arch>-cpu-<model>"? > > Fine with me. However, keep in mind the previous approach was used for > command line compatibility: I would like to continue using -cpu > cortex-a9 rather than -cpu arm-cpu-cortex-a9. :)
Me too. We need keep "-cpu SandyBridge" working, instead of requiring "-cpu x86_64-cpu-SandyBridge". "-cpu FOO" could first try a class named "<arch>-cpu-FOO" (for compatibility), then fallback to "FOO". > > If we introduce a more complex command-line-to-class mapping, can't we > drop these ominous "any" CPUs altogether? For my understanding they were > used as wildcard CPUs for *-user. We could do the same by instantiating > a real CPU like "cortex-a15" and possibly enabling some additional > features afterwards. I didn't look so deeply at the code, to understand what "any" does, and why it exists. But whatever we do, I suppose we need to keep "-cpu any" working, for compatibility. > > Andreas > > >>> Maybe we should use > >>> "cpu-<model>" as the namespace for the CPU model class names? > >> > >> Sounds reasonable. > >> > >> -- PMM > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- Eduardo