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