On Mon, 15 Apr 2013 12:47:52 -0300 Eduardo Habkost <ehabk...@redhat.com> wrote:
> 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. Objection here http://lists.nongnu.org/archive/html/qemu-devel/2013-04/msg01332.html In case of x86, it might be firmware defined id, but in general case it might be not the case, since it could be hardwired into CPU. So get_arch_id() seems more appropriate. > > 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 > -- Regards, Igor
