Date: Mon, 11 Aug 2014 17:31:42 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: RFC: cpuid_t Message-ID: <CAJ-VmokBege99hB04gwGx5904VGAeso2HY%2B06Koy0UK5rqepWw@mail.gmail.com> In-Reply-To: <201408111218.29802.jhb@freebsd.org> References: <CAJ-VmomJdq8PaFun=f4vzQUvnVvY%2BL6-Nz5rVPUw7MHB-2J4Eg@mail.gmail.com> <20140810060747.V855@besplex.bde.org> <201408111218.29802.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokBege99hB04gwGx5904VGAeso2HY%2B06Koy0UK5rqepWw>