From owner-freebsd-arch@FreeBSD.ORG Tue Aug 12 19:37:06 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6A1FD9E for ; Tue, 12 Aug 2014 19:37:06 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B23125C8 for ; Tue, 12 Aug 2014 19:37:06 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 141CBB93A; Tue, 12 Aug 2014 15:37:05 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: RFC: cpuid_t Date: Tue, 12 Aug 2014 09:39:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201408111218.29802.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201408120939.56176.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 12 Aug 2014 15:37:05 -0400 (EDT) Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 19:37:07 -0000 On Monday, August 11, 2014 8:31:42 pm Adrian Chadd wrote: > On 11 August 2014 09:18, John Baldwin 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