Re: [Qemu-devel] [PATCH 08/19] cpu: introduce get_arch_id() method and override it for target-i386

[Igor Mammedov]

On Mon, 15 Apr 2013 12:47:52 -0300
Eduardo Habkost <address@hidden> 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 <address@hidden>
> > > ---
> > >  * 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