Re: cpuid_t typedef? (was Re: Processor cores not properly detected/activated?)

On Thursday, May 29, 2014 5:46:05 pm Adrian Chadd wrote:
> On 29 May 2014 14:29, John Baldwin <jhb_at_freebsd.org> wrote:
> > On Thursday, May 29, 2014 5:09:05 pm Adrian Chadd wrote:
> >> On 29 May 2014 13:18, John Baldwin <jhb_at_freebsd.org> wrote:
> >>
> >> >> anyway. Besides all of this - I'm thinking of just introducing:
> >> >>
> >> >> typedef uint32_t cpuid_t;
> >> >>
> >> >> .. then once we've converted all the users, we can make NOCPU
> >> >> something other than 255 (which is the other limiting factor here..)
> >> >>
> >> >> Any objections?
> >> >
> >> > This one is a bit harder as you'll have to do shims for kinfo_proc, but
> >> > I think this is fine.  You could also just use u_int, but a new foo_t
> >> > isn't that bad I guess.
> >>
> >> I don't think I'd modify any userland-facing ABI/KBI's just yet. I'm
> >> just worried that 11.0-REL will come out before we have made a decent
> >> inroads into this and we _can't_ support > 254 CPUs.
> >
> > Eh, that's one of the biggies to do actually.   Kind of pointless to
> > update td_oncpu/lastcpu and not fix kinfo_proc at the same time.  You'll
> > just have to add new int fields and populate the old ones with sane values
> > for CPUs < 255.
> 
> Ugh. Ok. I was too deep in the trenches of device drivers and other
> ancillary things doing bad things to char/short with cpu ids when
> walking things. I totally missed kinfo_proc.
> 
> I'll go think about it a bit more.

It shouldn't be too hard to to handle kinfo_proc.  pf is another case.  It 
might be nice to have a way to auto-compute the right number of bits to 
reserve based on MAXCPU.

-- 
John Baldwin