Date: Thu, 14 Aug 2014 10:12:13 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: RFC: cpuid_t Message-ID: <CAJ-Vmon=sMxJQ4NEjj0zFNnXCCH66%2Bq77OgTAD7B13%2B0PfBBjg@mail.gmail.com> In-Reply-To: <201408141143.01137.jhb@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >> 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. > > 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. (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.) -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmon=sMxJQ4NEjj0zFNnXCCH66%2Bq77OgTAD7B13%2B0PfBBjg>