Peter Maydell <[email protected]> writes: > On 21 February 2017 at 12:44, Igor Mammedov <[email protected]> wrote: >> If we are to ditch legacy approach, >> It would be cleaner for SoC to have fixed/unconfigurable >> CPU type and each SoC being modeled as a separate >> QOM object/type that would instantiate CPU directly >> with QOM style, using type name, like: >> >> cpu = object_new(TYPE_FOO_CPU) >> set props if necessary >> object_property_set_bool(cpu, true, "realized", &err) >> object_unref(cpu) >> >> or similar with extra check/logic on top of plain object_new() >> >> prepare cpu_opts for cpu type TYPE_FOO_CPU >> cpu = qdev_device_add(cpu_opts) >> object_unref(cpu) >> >> instead of using cpu_init/cpu_foo_init/cpu_generic_init() >> with cpu_model parsing logic which is not really needed >> there as concrete SoC model knows exact CPU type. > > Mmm, I think that's probably best. Would the end-user > still be able to set CPU properties if necessary via > a -global command line switch (since -cpu type,foo=on > wouldn't work)?
-global is a qdev thing. It affects only instances of TYPE_DEVICE and its subtypes. Since TYPE_CPU is one... > (I just worry slightly that we might have users doing > weird things which we'd break.) I suspect we'd hand out a foot or two of extra rope, in addition to the miles our users already got.
