On Mon, Apr 15, 2013 at 05:24:36PM +0200, Andreas Färber wrote: > Am 11.04.2013 16:51, schrieb Igor Mammedov: > > get_arch_id() adds possibility for generic code to get guest visible > > CPI id without accessing CPUArchState. If target doesn't override it, > > it will return cpu_index. > > > > Override it on target-i386 to return APIC ID. > > > > Signed-off-by: Igor Mammedov <imamm...@redhat.com> > > --- > > * it will be used later by new cpu_exists() generic function and > > acpi_piix. > > * s/cpu_firmware_id/cpu_arch_id/ > > --- > > include/qom/cpu.h | 2 ++ > > qom/cpu.c | 6 ++++++ > > target-i386/cpu.c | 10 ++++++++++ > > 3 files changed, 18 insertions(+) > > I'm still unclear about this ID topic, but please don't add QOM methods > with arch_ in the name. The arch is expressed through subclasses.
The naming seemed appropriate to me as it is an abstract method that is expected to have arch-specific implementations and arch-specific meaning. On the other hand, "firmware_id" looked clearer to me (as it was very specific about the meaning/usefulness of the return value), I don't know what was the original reason to change from firmware_id to arch_id. Other than "arch_id" and "firmware_id , I don't know how we could name that method. It's not "just an ID", but a special kind of ID, so I believe just "cpu_id" wouldn't work. -- Eduardo
