From owner-freebsd-arch@FreeBSD.ORG Mon Aug 11 21:28:56 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 08067265 for ; Mon, 11 Aug 2014 21:28:56 +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 D2AB42707 for ; Mon, 11 Aug 2014 21:28:55 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A8C54B94A; Mon, 11 Aug 2014 17:28:54 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: RFC: cpuid_t Date: Mon, 11 Aug 2014 12:18:29 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20140810060747.V855@besplex.bde.org> In-Reply-To: <20140810060747.V855@besplex.bde.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201408111218.29802.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 11 Aug 2014 17:28:54 -0400 (EDT) Cc: Adrian Chadd 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: Mon, 11 Aug 2014 21:28:56 -0000 On Saturday, August 09, 2014 5:16:26 pm Bruce Evans wrote: > On Sat, 9 Aug 2014, Adrian Chadd wrote: > > > How's this look? > > Not good. > > > Index: sys/sys/_types.h > > =================================================================== > > --- sys/sys/_types.h (revision 269480) > > +++ sys/sys/_types.h (working copy) > > @@ -52,6 +52,7 @@ > > typedef __uint16_t __nlink_t; /* link count */ > > typedef __int64_t __off_t; /* file offset */ > > typedef __int32_t __pid_t; /* process [group] */ > > +typedef __uint32_t __cpuid_t; /* CPU ID */ > > typedef __int64_t __rlim_t; /* resource limit - intentionally */ > > /* signed, because of legacy code */ > > /* that uses -1 for RLIM_INFINITY */ > > Unsorting. In the English alphabet, c is not between p and r. > > The whitespace seems to be inconsistent, but the mail corrupted all the > tabs so it is hard to tell. > > > Index: sys/sys/types.h > > =================================================================== > > --- sys/sys/types.h (revision 269480) > > +++ sys/sys/types.h (working copy) > > @@ -154,6 +154,11 @@ > > #define _LWPID_T_DECLARED > > #endif > > > > +#ifndef _CPUID_T_DECLARED > > +typedef __cpuid_t cpuid_t; /* CPU ID */ > > +#define _CPUID_T_DECLARED > > +#endif > > + > > #ifndef _MODE_T_DECLARED > > typedef __mode_t mode_t; /* permissions */ > > #define _MODE_T_DECLARED > > Unsorting. c is also not between l and m. > > The comment is banal, like many nearby ones. It does less than echo the > code. Most for ids at least echo the code by repeating "id" in lower case. > > In private mail, I said that this typedef is less needed than one for > file descriptors. Since the latter need is negative, the need for this > one is very negative. Ids should be small integers so that they can be > used directly as array indexes, unless they need to cover a large sparse > namespace so that they need to be hash numbers. 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). -- John Baldwin