OK, sounds good - I might be twisting it with the SMP code, which I'm much
more familiar with.
>> boot_cpu_physical_apicid = hard_smp_processor_id();
>> phys_cpu_present_map = 1 << boot_cpu_physical_apicid;
>
> But is it necessarily true that hard_smp_processor_id() equals the APIC
> id?
Well it should be. Except that someone did this for some odd reason
#define hard_smp_processor_id() 0
on non-SMP rather than non-local-apic.
But we could just substitute the real code:
static __inline int hard_smp_processor_id(void)
{
/* we don't want to mark this access volatile - bad code generation
*/
return GET_APIC_ID(*(unsigned long *)(APIC_BASE+APIC_ID));
}
which is in smp.h, but wrapped in #ifdef CONFIG_X86_LOCAL_APIC.
All very twisted. Probably not worth it.
> and that's just about as good as it gets, certainly the CPU knows best
> what its APIC id is.
Absolutely ;-)
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/