Date: Tue, 12 Aug 2014 09:39:56 -0400 From: John Baldwin <jhb@freebsd.org> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: RFC: cpuid_t Message-ID: <201408120939.56176.jhb@freebsd.org> In-Reply-To: <CAJ-VmokBege99hB04gwGx5904VGAeso2HY%2B06Koy0UK5rqepWw@mail.gmail.com> References: <CAJ-VmomJdq8PaFun=f4vzQUvnVvY%2BL6-Nz5rVPUw7MHB-2J4Eg@mail.gmail.com> <201408111218.29802.jhb@freebsd.org> <CAJ-VmokBege99hB04gwGx5904VGAeso2HY%2B06Koy0UK5rqepWw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, August 11, 2014 8:31:42 pm Adrian Chadd wrote: > On 11 August 2014 09:18, John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201408120939.56176.jhb>