From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 02:15:26 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 BB56FC3C; Fri, 15 Aug 2014 02:15:26 +0000 (UTC) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 4BD9F20EB; Fri, 15 Aug 2014 02:15:25 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id DC3381A2044; Fri, 15 Aug 2014 12:15:16 +1000 (EST) Date: Fri, 15 Aug 2014 12:15:16 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Adrian Chadd Subject: Re: RFC: cpuid_t In-Reply-To: Message-ID: <20140815113509.F1151@besplex.bde.org> References: <201408120939.56176.jhb@freebsd.org> <201408141143.01137.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=BdjhjNd2 c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=6I5d2MoRAAAA:8 a=PdWYHDfVZEZrx_OGp8wA:9 a=Y3Ydrqqc73HhMB8v:21 a=i40qTmOqVJtlgkuw:21 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 02:15:26 -0000 On Thu, 14 Aug 2014, Adrian Chadd wrote: > On 14 August 2014 08:43, John Baldwin wrote: >> On Tuesday, August 12, 2014 6:17:27 pm Adrian Chadd wrote: >>> On 12 August 2014 06:39, John Baldwin 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