Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932717AbcLMAzG convert rfc822-to-8bit (ORCPT ); Mon, 12 Dec 2016 19:55:06 -0500 Received: from mga06.intel.com ([134.134.136.31]:46688 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752971AbcLMAzD (ORCPT ); Mon, 12 Dec 2016 19:55:03 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,339,1477983600"; d="scan'208";a="41636608" From: "Dilger, Andreas" To: James Simmons CC: Greg Kroah-Hartman , "devel@driverdev.osuosl.org" , James Simmons , Linux Kernel Mailing List , "Drokin, Oleg" , Lustre Development List Subject: Re: [PATCH v2 5/5] staging: lustre: headers: use proper byteorder functions in lustre_idl.h Thread-Topic: [PATCH v2 5/5] staging: lustre: headers: use proper byteorder functions in lustre_idl.h Thread-Index: AQHSVNuIr4cMxX07y0+mwZCY7pkNVQ== Date: Tue, 13 Dec 2016 00:55:01 +0000 Message-ID: <73FD0668-EDE9-4757-98ED-8A15CE5DA17C@intel.com> References: <1481393161-22623-1-git-send-email-jsimmons@infradead.org> <1481393161-22623-6-git-send-email-jsimmons@infradead.org> <20161210181649.GB8477@kroah.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.103.237] Content-Type: text/plain; charset="us-ascii" Content-ID: <441254CB60A0564CB2A3402DE617D4FB@intel.com> Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1688 Lines: 35 On Dec 12, 2016, at 13:00, James Simmons wrote: > > >> On Sat, Dec 10, 2016 at 01:06:01PM -0500, James Simmons wrote: >>> In order for lustre_idl.h to be usable for both user >>> land and kernel space it has to use the proper >>> byteorder functions. >> >> Why would userspace need/want all of these inline functions? A uapi >> header file should just have a the structures that are passed >> user/kernel and any needed ioctls. Why would they ever care about >> strange byte flip functions and a ton of inline functions? >> >> I don't think this is needed, of if it is, I really don't want to see >> your crazy userspace code... > > Sigh. More cleanups were done based on the idea this was okay. The > reason this was does was when you look at the headers in > include/uapi/linux you see a huge number of headers containing a bunch > of inline function. To an outside project looking to merge their work > into the kernel they would think this is okay. Hopefully all those > broken headers will be cleaned up in the near future. > Alright I will look to fixing up our tools to handle this requirement. These accessor functions are used by both the kernel and userspace tools, and keeping them in the lustre_idl.h header avoids duplication of code. Similar usage exists in other filesystem related uapi headers (e.g. auto_fs4.h, bcache.h, btrfs_tree.h, nilfs2_ondisk.h, swab.h, etc.). That said, if there is an objection to keeping these macros/inline funcs in the uapi headers, they still need to exist in the kernel and should be kept in the lustre/include/lustre directory and we'll keep a separate copy of the macros for userspace. Cheers, Andreas