From owner-freebsd-arch@FreeBSD.ORG Tue Aug 12 00:31:43 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 8128D5AB; Tue, 12 Aug 2014 00:31:43 +0000 (UTC) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3347C2A05; Tue, 12 Aug 2014 00:31:43 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id l6so2266356qcy.33 for ; Mon, 11 Aug 2014 17:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8DrnTpjHGm/cHKMbtCOtfvzGhI9Y1L/FlwlXvTPiFMk=; b=YWDiTQptD4VHwafvzc0HOKA/GIMYVg30bX3QgNK6+Df5xq0nEah9rG3LwTyJVwvqPg Yn8nnc5WxgYDBgVRIyZM9qGrOknGfE2lsKjPYy7lLJ27pMpOElwVYZFLlmC2dgw+1Bji VuCjZqIXa9tfkVij7Bm1k5o4X84vnxU+jERAah39utdaEj6IFIUXhznyMEoRIP5+asLx AzzvS1i50gw34Suup4c0VRAGyq1bX/TbwT2VduVkI4AeOSQz2+3VTkJtLSyzxiXyy7Kb j2YztGavPYoCvSdhf5PjYdw1aWMEdauDSPVQ9Hssq5SLEd3KejyAFhBwQTUT92WLCu/o qRYA== MIME-Version: 1.0 X-Received: by 10.224.15.195 with SMTP id l3mr1286389qaa.98.1407803502424; Mon, 11 Aug 2014 17:31:42 -0700 (PDT) Received: by 10.224.41.6 with HTTP; Mon, 11 Aug 2014 17:31:42 -0700 (PDT) In-Reply-To: <201408111218.29802.jhb@freebsd.org> References: <20140810060747.V855@besplex.bde.org> <201408111218.29802.jhb@freebsd.org> Date: Mon, 11 Aug 2014 17:31:42 -0700 Message-ID: Subject: Re: RFC: cpuid_t From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 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 00:31:43 -0000 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. -a