Date: Fri, 15 Aug 2014 12:15:16 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: RFC: cpuid_t Message-ID: <20140815113509.F1151@besplex.bde.org> In-Reply-To: <CAJ-Vmon=sMxJQ4NEjj0zFNnXCCH66%2Bq77OgTAD7B13%2B0PfBBjg@mail.gmail.com> References: <CAJ-VmomJdq8PaFun=f4vzQUvnVvY%2BL6-Nz5rVPUw7MHB-2J4Eg@mail.gmail.com> <201408120939.56176.jhb@freebsd.org> <CAJ-VmonLOiqCkQGfAq=ZaJnJXtBGY=iuKRrnL4Kfnsiong8j1g@mail.gmail.com> <201408141143.01137.jhb@freebsd.org> <CAJ-Vmon=sMxJQ4NEjj0zFNnXCCH66%2Bq77OgTAD7B13%2B0PfBBjg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 14 Aug 2014, Adrian Chadd wrote:
> On 14 August 2014 08:43, John Baldwin <jhb@freebsd.org> wrote:
>> On Tuesday, August 12, 2014 6:17:27 pm Adrian Chadd wrote:
>>> On 12 August 2014 06:39, John Baldwin <jhb@freebsd.org> wrote:
>>>
>>>> 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.
>>>
>>> You could do that, but then we'd be left in a situation that it isn't
>>> 100% clear what type people should be using (except hoping they
>>> cut/paste code that uses an int and don't make dumb decisions like
>>> assuming they can pack it into other fields, like pf) and that they
>>> could treat the CPU ID as some kind of index number. Being able to
>>> grep for all the places where cpuid_t is will make it a lot easier in
>>> the future to uplift all of the cpu id manipulating code to treat CPU
>>> IDs differently (eg making things very sparse.)
>>
>> I'm not sure how a typedef makes it easier to handle sparse IDs over an int?
>> Plus, the IDs are already allowed to be sparse (hence CPU_ABSENT() and
>> CPU_FOREACH(), etc.). I doubt that a typedef would make it any easier to
>> deal with issues like pf either because the current code is not explicitly
>> using any type at all, it's just passed into magic macros.
>
> It doesn't. It's there to help you find places where people aren't
> doing the iteration correctly.
>
> You can do tricks like making cpuid_t temporarily a struct with the
> int embedded in it: it'll work fine where it's being copied around as
> an opaque type, but it'll compiler error out the minute some code
> tries passing it into a field that takes an int, or a char.
That is good for debugging and converting, but too complex to commit and
maintain forever. It is only feasible because CPU ids are so rarely
used. You wouldn't be able to do this for file descriptors.
>>> So, I'm happy if the group decision is to just make it an int. It just
>>> has to be done before FreeBSD-11 ships. :)
>>
>> I think making it an int would be a good first step at the very least. It
>> would be good to see how many places don't already use it that way.
>>
>>> I don't have such an aversion to typedefs. It has always made it much
>>> easier to do type checking and changes to things in C that I'd
>>> normally do in C++ with classes.
They aren't much use in C.
>> One downside is that for printf() (a non-trivial thing in C), you have to
>> either violate the abstraction (i.e. "know" it's an int) or use intmax_t casts
>> everywhere.
>
> That's why you have a cpuid_t_to_quad() macro and use that everywhere
> you need a numerical representation of the ID. That way it's up to the
> macro or inline to return it as the type you require and thus printf()
> and friends can have a well-known type in the string.
That's mainly just harder to write and debug.
> (I dislike intmax_t casts. I'd rather there were explicit ways to
> convert those types to integer representations where appropriate
> rather than having the code do those casts just to print. Ugh.)
So you want everything to do explicit conversions and be more painful
to write than a cast?:
foo[cpuid_to_index(cpuid)] = ...
printf("%qd", cpuid_to_quad(cpuid));
I made this more painful than necessary by providing more than 1 conversion
function. Otherwise, the large quad type used to give a large fixed
format for printing would unnecessarily pessimize everything. Conversion
for indexing is only needed if cpuid is only a cookie that needs conversion.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140815113509.F1151>