RFC: cpuid_t

[John Baldwin]

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