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=-0.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 A2E52C04A6B for ; Wed, 8 May 2019 09:19:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0EFA620656 for ; Wed, 8 May 2019 09:19:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727175AbfEHJT4 convert rfc822-to-8bit (ORCPT ); Wed, 8 May 2019 05:19:56 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([207.82.80.151]:48554 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726740AbfEHJT4 (ORCPT ); Wed, 8 May 2019 05:19:56 -0400 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-20-fr8XoZJNPVSqTqULhvI6mg-1; Wed, 08 May 2019 10:19:52 +0100 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b::d117) by AcuMS.aculab.com (fd9f:af1c:a25b::d117) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 8 May 2019 10:19:51 +0100 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Wed, 8 May 2019 10:19:51 +0100 From: David Laight To: 'Alastair D'Silva' , "alastair@d-silva.org" CC: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , "Dan Carpenter" , 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 , Petr Mladek , 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 v2 4/7] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags Thread-Topic: [PATCH v2 4/7] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags Thread-Index: AQHVBWwP4v5z/92cRUaSHokPgMaM4aZg8Maw Date: Wed, 8 May 2019 09:19:51 +0000 Message-ID: References: <20190508070148.23130-1-alastair@au1.ibm.com> <20190508070148.23130-5-alastair@au1.ibm.com> In-Reply-To: <20190508070148.23130-5-alastair@au1.ibm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-MC-Unique: fr8XoZJNPVSqTqULhvI6mg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org From: Alastair D'Silva > Sent: 08 May 2019 08:02 > To: alastair@d-silva.org ... > --- a/include/linux/printk.h > +++ b/include/linux/printk.h > @@ -480,13 +480,13 @@ enum { > DUMP_PREFIX_OFFSET > }; > > -extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize, > - int groupsize, char *linebuf, size_t linebuflen, > - bool ascii); > - > #define HEXDUMP_ASCII (1 << 0) > #define HEXDUMP_SUPPRESS_REPEATED (1 << 1) These ought to be BIT(0) and BIT(1) > +extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize, > + int groupsize, char *linebuf, size_t linebuflen, > + u64 flags); Why 'u64 flags' ? How many flags do you envisage ?? Your HEXDUMP_ASCII (etc) flags are currently signed values and might get sign extended causing grief. 'unsigned int flags' is probably sufficient. I've not really looked at the code, it seems OTT in places though. If someone copies it somewhere where the performance matters (I've user space code which is dominated by its tracing!) then you don't want all the function calls and conditionals even if you want some of the functionality. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)