From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCFF7C10F14 for ; Fri, 12 Apr 2019 13:48:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AE45020850 for ; Fri, 12 Apr 2019 13:48:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727103AbfDLNsI (ORCPT ); Fri, 12 Apr 2019 09:48:08 -0400 Received: from mx2.suse.de ([195.135.220.15]:48048 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726842AbfDLNsH (ORCPT ); Fri, 12 Apr 2019 09:48:07 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id CB555AD63; Fri, 12 Apr 2019 13:48:04 +0000 (UTC) Date: Fri, 12 Apr 2019 15:48:02 +0200 From: Petr Mladek To: Alastair D'Silva Cc: alastair@d-silva.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , Karsten Keil , Jassi Brar , Tom Lendacky , "David S. Miller" , Jose Abreu , Kalle Valo , Stanislaw Gruszka , Benson Leung , Enric Balletbo i Serra , "James E.J. Bottomley" , "Martin K. Petersen" , Greg Kroah-Hartman , Alexander Viro , Sergey Senozhatsky , Steven Rostedt , Andrew Morton , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, ath10k@lists.infradead.org, linux-wireless@vger.kernel.org, linux-scsi@vger.kernel.org, linux-fbdev@vger.kernel.org, devel@driverdev.osuosl.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH 1/4] lib/hexdump.c: Allow 64 bytes per line Message-ID: <20190412134802.kprel2c2iqijd4ai@pathway.suse.cz> References: <20190410031720.11067-1-alastair@au1.ibm.com> <20190410031720.11067-2-alastair@au1.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190410031720.11067-2-alastair@au1.ibm.com> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Wed 2019-04-10 13:17:17, Alastair D'Silva wrote: > From: Alastair D'Silva > > With modern high resolution screens, we can display more data, which makes > life a bit easier when debugging. I have quite some doubts about this feature. We are talking about more than 256 characters per-line. I wonder if such a long line is really easier to read for a human. I am not expert but there is a reason why the standard is 80 characters per-line. I guess that anything above 100 characters is questionable. https://en.wikipedia.org/wiki/Line_length somehow confirms that. Second, if we take 8 pixels per-character. Then we need 2048 to show the 256 characters. It is more than HD. IMHO, there is still huge number of people that even do not have HD display, especially on a notebook. I am sorry but I am strongly against having this hardcoded anywhere. And I doubt that there will be enough users to complicate the code and make it configurable. Best Regards, Petr