[rfc] where to put cpuid_t ?

[Robert Watson]

On Thu, 24 Jul 2014, Adrian Chadd wrote:

> I've been chipping away at a cpuid_t in a local branch for a while and I 
> think I have the very basics working well enough.
>
> However, the most annoying thing that's crept up is the most bikeshed topic 
> of them all - where should it live.
>
> I'd like to avoid having to include sys/pcpu.h or sys/_cpuset.h just for the 
> id type - it seems a bit overkill.
>
> So - suggestions? Otherwise I'm going to leave it in sys/pcpu.h and just 
> polluate appropriately.
>
> I'd like to try and get cpuid_t and a handful of KBI-changing things into 
> -HEAD before 11 is branched so we at least have a hope of trying to support 
> > 128 CPUs out of the box in the immediate future and > 253 CPUs in the 
> later future.

Sounds like bikeshed fodder.  Usually you end up with widely used core types 
in _types.h or _foo.h, with some notion of publiciness being defined in 
types.h, param.h, or foo.h.  I'd leave it where it is until you discover you 
need the header everywhere or nested all over the place, in which case I'd 
then shift it to a centralised header.

At least for SRI and Cambridge, the ability to name a few hundred 
cores/threads is concern that will arise later this year.  I'd like to see a 
CPU ID type that can represent >128 threads almost immediately -- ideally no 
less than 512 in the beginning of next year as hardware starts to come 
together.

(In case anyone is wondering where we find such hardware: we use FPGA-based 
soft-core processors in our research, and are about to move from a single-FPGA 
platform which typically hosts a smallish numbers of cores and threads to a 
multi-FPGA platform which could lead to quite fast growth in core count, and 
also quite NUMAish properties.  We can time-division multiplex core 
implementations on FPGAs leading to many more virtual than physical cores).

Robert