From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754404AbcBIMyG (ORCPT ); Tue, 9 Feb 2016 07:54:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37470 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751089AbcBIMyD (ORCPT ); Tue, 9 Feb 2016 07:54:03 -0500 Subject: Re: [PATCH 14/14] x86/efi: Print size in binary units in efi_print_memmap To: Ingo Molnar , "Elliott, Robert (Persistent Memory)" References: <1454364428-494-1-git-send-email-matt@codeblueprint.co.uk> <1454364428-494-15-git-send-email-matt@codeblueprint.co.uk> <56B0756E.9010603@redhat.com> <20160203104045.GB7310@gmail.com> <20160203112829.GC2597@codeblueprint.co.uk> <94D0CD8314A33A4D9D801C0FE68B40295BF72A9F@G4W3202.americas.hpqcorp.net> <20160209122018.GA4178@gmail.com> Cc: Matt Fleming , "H . Peter Anvin" , Thomas Gleixner , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Andy Shevchenko , Ard Biesheuvel , Taku Izumi , Linus Torvalds , Andrew Morton From: Laszlo Ersek Message-ID: <56B9E166.6030405@redhat.com> Date: Tue, 9 Feb 2016 13:53:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160209122018.GA4178@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/09/16 13:20, Ingo Molnar wrote: > > * Elliott, Robert (Persistent Memory) wrote: > >> >>> -----Original Message----- >>> From: Matt Fleming [mailto:matt@codeblueprint.co.uk] >>> Sent: Wednesday, February 3, 2016 5:28 AM >>> To: Ingo Molnar >>> Cc: Laszlo Ersek ; H . Peter Anvin ; >>> Thomas Gleixner ; linux-efi@vger.kernel.org; linux- >>> kernel@vger.kernel.org; Elliott, Robert (Persistent Memory) >>> ; Andy Shevchenko ; >>> Ard Biesheuvel ; Taku Izumi >>> ; Linus Torvalds >> foundation.org>; Andrew Morton >>> Subject: Re: [PATCH 14/14] x86/efi: Print size in binary units in >>> efi_print_memmap >> ... >>> OK, this patch has caused enough headaches. Let's drop it from this >>> series. >>> >>> Robert, Andy, feel free to resubmit it after you've addressed >>> everyone's concerns and we can discuss it in isolation. >> >> We could just delete the size print altogether - better to print >> nothing than a silently rounded number. The end address already >> communicates the size - it's just not as readable. >> >> The e820 table prints don't bother with a size print. >> >> That would also shorten these extremely wide prints to 116 >> characters (131 if printk time is enabled). >> >> [ 0.000000] BIOS-e820: [mem 0x0000001880000000-0x000000207fffffff] reserved >> vs. >> [ 0.000000] efi: mem62: [Reserved | | |NV| | | | | |WB|WT|WC|UC] range=[0x0000001880000000-0x000000207fffffff] (32 GiB) > > So I find the latter a lot more readable - my terminals are wide enough ;-) > > Humans are also rather bad at parsing 64-bit hexa address ranges at a glance, so > the size display is very useful. > > But the flags portion should be shortened via appropriately chosen > single-character abbreviations for the flags. Anyone deeply intimate with the code > will recognize the flags - others won't care one way or another. > > plus there's no need to write out 'range='. > > ... and please keep the size and just use GB/TB for chrissake. > > I.e. something like this would work for me: > >> [ 0.000000] efi: mem62: 0x0000001880000000-0x000000207fffffff ( 32 GB) .N....BTCU "Reserved" Sorry to disagree :), but I count myself somewhat intimate with UEFI (albeit more from the edk2 side), and while I can make sense of |NV| | | | | |WB|WT|WC|UC] I find .N....BTCU mostly undecipherable. :) My original goal with this printout was to (a) provide a good impression of the entire UEFI memmap, at a glance, (b) provide sufficient detail per-entry, if necessary. (I don't exactly recall why I was staring at the UEFI memmap dump at that time, maybe I was working on S3 in OVMF which took a lot of memmap massaging, or debugging some bug; either way my eyes were bleeding trying to decode the numeric attributes.) My xterm, maximized, has 239 columns, which I think counts as pretty low for today's resolutions. It is nonetheless plenty wide for the current output. Given that we print this stuff only when debugging information is requested, I feel that the value of the current columnar output, in which I can follow a single attribute with my eye across all entries, should not be diminished, by compressing the columns. I'm not a wide screen maniac; for example I insist on source code being wrapped at 79 characters, commit messages at 74, emails at 72 (except diagrams and log excerpts), and so on. But debug output is different. My 2 cents, of course... Thanks Laszlo