From owner-svn-src-head@FreeBSD.ORG Tue Sep 25 16:14:14 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABA3B1065700; Tue, 25 Sep 2012 16:14:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6104F8FC16; Tue, 25 Sep 2012 16:14:14 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2c64:e0f1:ab25:e270] (unknown [IPv6:2001:7b8:3a7:0:2c64:e0f1:ab25:e270]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6A2235C59; Tue, 25 Sep 2012 18:14:07 +0200 (CEST) Message-ID: <5061D84D.4020400@FreeBSD.org> Date: Tue, 25 Sep 2012 18:14:05 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: John Baldwin References: <201209211031.q8LAVKVC014601@svn.freebsd.org> <201209250807.46163.jhb@freebsd.org> In-Reply-To: <201209250807.46163.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r240773 - in head/sys: amd64/amd64 i386/i386 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 16:14:14 -0000 On 2012-09-25 14:07, John Baldwin wrote: > On Friday, September 21, 2012 6:31:20 am Dimitry Andric wrote: >> Author: dim >> Date: Fri Sep 21 10:31:19 2012 >> New Revision: 240773 >> URL: http://svn.freebsd.org/changeset/base/240773 >> >> Log: >> After r205013, amd64 and i386 CPU family and model IDs were printed out >> in hexadecimal, but without any 0x prefix, which can be very misleading. >> >> MFC after: 3 days > > This overflows 80 columns now where it did not before. Ehm, most of dmesg lines overflow 80 columns; in fact, the lines just below this print the CPU feature bits, which are easily a few wrapped lines long. So I don't really see the point in obfuscating those numbers. Are we interested more in "beautifying", than giving unambiguous information? > Intel manuals tend > to use a trailing 'h' suffix rather than an '0x' prefix. (It is common to > see text like '06_2Ah'.) The prefix was previously left off on purpose due to > the 80 colummns overflow. I think that was a mistake, if something is hexadecimal, it should be clearly indicated, otherwise it is extremely confusing. Intel assembly is basically the only variant still out there using the 'h' suffix, the rest of the (C) world uses 0x. :)