RFC: cpuid_t

[John Baldwin]

On Monday, August 11, 2014 8:31:42 pm Adrian Chadd wrote:
> On 11 August 2014 09:18, John Baldwin <jhb at freebsd.org> wrote:
> 
> > You would just prefer an int then?  Your point about it being used in 
kinfo
> > is well-taken (meaning that once it is part of an ABI you can't actually
> > change it transparently).  I know Adrian is currently concerned about 
doing
> > the initial sweep to identify the places that store CPU IDs and marking 
them
> > as such, and I believe he sees value in simply enumerating the places that
> > are CPU IDs rather than something else.  It is true that cpuset_t 
currently
> > assumes it represents a set of integers (more or less) and the closes 
analogy
> > to that (signals) just use plain int for signal numbers (and not a sig_t 
or
> > the like).
> 
> Right.
> 
> Right now I think we're stuck in the really stupid position that:
> 
> * > 253 "schedulable entity" machines exist right now (think all that
> silly sparc hardware that exists);
> * and > 253 core Intel/AMD machines are going to show up soon;
> * along with that weird MIPS project that Robert and co are working on;
> * .. but I'm trying to tackle this as a "fun, spare time project."
> 
> So my approach is designed to make it easy to get some changes into
> the tree without waiting for "final" thing to show up before commiting
> it.
> 
> Ie:
> 
> * a char / u_char / something variable and non-defined is going to
> bite us during the FreeBSD-11 timeframe;
> * so I'd rather spend my time enumerating all the places a cpu
> identifier is used and, well, change it to cpuid_t without changing
> anything else about the behaviour;
> * .. and fix whatever basic API things show up because of that - john
> and bruce have both shown me some of those;
> * .. then stop at that - (eg, I'm not going to try and fix all the
> places where cpuid_t is used as some "thing" to iterate from/to) -
> that makes iterating over a sparse set of CPU IDs rather .. amusing;
> * then at some later stage we can hammer out a more stable API -
> likely as part of FreeBSD-12.
> 
> I'm under no real expectation that we're going to get this _right_
> given the FreeBSD-11 timeframe and that I'm doing this as a spare time
> project.
> 
> However, i want to get at least the more dumb dumbness out of the tree
> before we branch 11 so if we do have to change anything to do with
> userland ABI, it'll hurt "less". I'd like to be able to use grep to
> figure out where all the users of a cpu id are so we have a reasonably
> tractable place to start in fixing things, as well as laying down some
> basic API rules for the future (eg, no new function calls that
> manipulate something about a cpu_id should be passing in a char or
> u_char - and this did just happen recently.)
> 
> So, I'd like to focus more on getting the typedef into there and in
> the right place - so thankyou Bruce, I do appreciate the feedback and
> I'm going to fix things before I submit this again.

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.

-- 
John Baldwin