On Wed, 17 Jan 2018 20:30:14 +0000
Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 17 January 2018 at 19:15, Igor Mammedov <imamm...@redhat.com> wrote:
> > On Wed, 17 Jan 2018 16:12:09 +0000
> > Peter Maydell <peter.mayd...@linaro.org> wrote:
> >> I like moving this from being an ifdef ladder into per-cpu
> >> code, but I don't think the definition belongs in target/$ARCH.
> >> It's part of the choice usermode makes about how to handle
> >> binaries it's loading, so it should go in linux-user/$ARCH/target_cpu.h.
> >> target/$ARCH should really be for things that are properties
> >> of the architecture.
> > That's used not only by linux-user but also reused by null-machine.c
> > to get access to a target specific cpu_class_by_name() callback.
>
> That usage must want a different name, though, surely?
> For Arm the default CPU for linux-user is 'any' but that
> is usermode only and won't work for system emulation so
> null-machine.c will need to pick something else.
not really in general as boards set their own default types
and secondly it applies only to null-machine.
Though in both cases it work the same just fine because
current API works like this (system emulation)
vl.c:
current_machine->cpu_type = machine_class->default_cpu_type;
if (cpu_model) {
current_machine->cpu_type =
cpu_parse_cpu_model(machine_class->default_cpu_type,
cpu_model);
...
}
which would result for null-machine (patch 20/24) in:
cpu_parse_cpu_model(TARGET_DEFAULT_CPU_TYPE, cpu_model):
oc = cpu_class_by_name(TARGET_DEFAULT_CPU_TYPE, cpu_model):
cc = CPU_CLASS(object_class_by_name(TARGET_DEFAULT_CPU_TYPE))
cc->class_by_name(cpu_model)
so it doesn't really matter for system emulation what exact
type is used as a proxy to reach callback, as each target
implements only one cb in base CPU class and any leaf class
will work fine to reach the same class_by_name() cb.
So type that is default for linux-user can be abused for
this purpose and could be used as linux-default at
the same time.
Ugly and hackish, yes.
But it isolates cpu_model handling to a few places and
series removes API that uses it, so we won't have to
watch out for patches that would bring cpu_model
back into boards code after that.
On top of that, we could work on making cpu_parse_cpu_model()
API not to require proxy cpu type and that would affect
only 3 remaining callers in vl.c,bsd/linux-user/main.c
But that another re-factoring beyond the scope of this series,
which is already big as it is.
> thanks
> -- PMM
