RFC: cpuid_t

[Adrian Chadd]

On 12 August 2014 06:39, John Baldwin <jhb at freebsd.org> wrote:

> I think Bruce's point is you can just fix the few places that use a u_char to
> an int and call it a day.  The biggest offender of those that I can think of
> are td_oncpu/td_lastcpu and the corresponding fields in kinfo along with
> expanding NOCPU to be -1 instead of 255.  I think most other places already
> use an int (pf is one place that doesn't, it borrows N bits from some other
> field to store the CPU number, so it can't use a cpuid_t anyway), so the patch
> to just use an int might actually be quite small.

You could do that, but then we'd be left in a situation that it isn't
100% clear what type people should be using (except hoping they
cut/paste code that uses an int and don't make dumb decisions like
assuming they can pack it into other fields, like pf) and that they
could treat the CPU ID as some kind of index number. Being able to
grep for all the places where cpuid_t is will make it a lot easier in
the future to uplift all of the cpu id manipulating code to treat CPU
IDs differently (eg making things very sparse.)

So, I'm happy if the group decision is to just make it an int. It just
has to be done before FreeBSD-11 ships. :)

I don't have such an aversion to typedefs. It has always made it much
easier to do type checking and changes to things in C that I'd
normally do in C++ with classes.


-a