From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751901AbdFOQHg (ORCPT ); Thu, 15 Jun 2017 12:07:36 -0400 Received: from casper.infradead.org ([85.118.1.10]:59108 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750749AbdFOQHf (ORCPT ); Thu, 15 Jun 2017 12:07:35 -0400 Date: Thu, 15 Jun 2017 16:48:20 +0100 (BST) From: James Simmons To: Greg Kroah-Hartman cc: "Dilger, Andreas" , "Drokin, Oleg" , "devel@driverdev.osuosl.org" , Linux Kernel Mailing List , Lustre Development List Subject: Re: [lustre-devel] [PATCH] staging: lustre: headers: potential UAPI headers In-Reply-To: <20170613042531.GB13308@kroah.com> Message-ID: References: <1482167207-22800-1-git-send-email-jsimmons@infradead.org> <20170103141248.GA8695@kroah.com> <20170117074140.GA19328@kroah.com> <20170121092459.GA29138@kroah.com> <32AAAA94-0C88-40F5-8FAD-37F35A401AC3@intel.com> <20170613042531.GB13308@kroah.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20170615_164820_273176_0479B7A3 X-CRM114-Status: GOOD ( 30.53 ) X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.4.1 on casper.infradead.org summary: Content analysis details: (-1.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 NO_RELAYS Informational: message was not relayed via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Mon, Jun 12, 2017 at 08:20:15PM +0000, Dilger, Andreas wrote: > > On Jan 21, 2017, at 02:24, Greg Kroah-Hartman wrote: > > > > > > On Fri, Jan 20, 2017 at 11:33:11PM +0000, James Simmons wrote: > > >> > > >>>>> On Mon, Dec 19, 2016 at 12:06:47PM -0500, James Simmons wrote: > > >>>>>> Not for landing. This is the purposed UAPI headers > > >>>>>> with the removal of unlikely and debugging macros. > > >>>>>> This is just for feedback to see if this is acceptable > > >>>>>> for the upstream client. > > >>>>>> > > >>>>>> Signed-off-by: James Simmons > > >>>>>> --- > > >>>>>> .../lustre/lustre/include/lustre/lustre_fid.h | 353 +++++++++++++++++++++ > > >>>>>> .../lustre/lustre/include/lustre/lustre_ostid.h | 233 ++++++++++++++ > > >>>>> > > >>>>> Can you make a lustre "uapi" directory so we can see which files you > > >>>>> really want to be UAPI and which you don't as time goes on? > > I said that ^^^ > > > >>>> Where do you want them placed? In uapi/linux/lustre or uapi/lustre. Does > > >>>> it matter to you? The below was to forth coming UAPI headers which from > > >>>> your response you seem okay with in general. > > >>> > > >>> How many .h files are there going to be? It's just a single filesystem, > > >>> shouldn't you just need a single file? If so, how about > > >>> drivers/staging/lustre/include/uapi/lustre.h > > >>> ? > > >>> > > >>> If you really need multiple .h files, put them all in the same uapi/ > > >>> directory with a lustre_ prefix, you don't need a whole subdir just for > > >>> yourself, right? > > >> > > >> We have 12 UAPI headers and yes they all begin with lustre_*. Okay I will > > >> create a driver/staging/lustre/include/uapi/linux directory and start > > >> moving headers there. > > > > > > 12 seems like a lot just for a single, tiny, filesystem :) > > > > > > But moving them all to a single directory will see where we can later > > > merge them together, sounds like a good plan. > > > > Greg, > > are you really adamantly against moving the Lustre headers into their own lustre/ > > subdirectory? > > I did not say that. > > Please, when responding to 5 month old email messages, get your quoting > correct... So this is coming from trying to understand the "merge them together" part. Some people reading this it implies all the headers would be eventually merged into one big header and placed into include/uapi/linux. We are getting to the point where some sites are migrating from the out of tree branch to this client. This also means they will be moving external open source userland applications shortly. If we expose UAPI headers that are completely different that it breaks their tools users will dump this client and go back to the out source tree. We really like to avoid that. From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Simmons Date: Thu, 15 Jun 2017 16:48:20 +0100 (BST) Subject: [lustre-devel] [PATCH] staging: lustre: headers: potential UAPI headers In-Reply-To: <20170613042531.GB13308@kroah.com> References: <1482167207-22800-1-git-send-email-jsimmons@infradead.org> <20170103141248.GA8695@kroah.com> <20170117074140.GA19328@kroah.com> <20170121092459.GA29138@kroah.com> <32AAAA94-0C88-40F5-8FAD-37F35A401AC3@intel.com> <20170613042531.GB13308@kroah.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Greg Kroah-Hartman Cc: "Dilger, Andreas" , "Drokin, Oleg" , "devel@driverdev.osuosl.org" , Linux Kernel Mailing List , Lustre Development List > On Mon, Jun 12, 2017 at 08:20:15PM +0000, Dilger, Andreas wrote: > > On Jan 21, 2017, at 02:24, Greg Kroah-Hartman wrote: > > > > > > On Fri, Jan 20, 2017 at 11:33:11PM +0000, James Simmons wrote: > > >> > > >>>>> On Mon, Dec 19, 2016 at 12:06:47PM -0500, James Simmons wrote: > > >>>>>> Not for landing. This is the purposed UAPI headers > > >>>>>> with the removal of unlikely and debugging macros. > > >>>>>> This is just for feedback to see if this is acceptable > > >>>>>> for the upstream client. > > >>>>>> > > >>>>>> Signed-off-by: James Simmons > > >>>>>> --- > > >>>>>> .../lustre/lustre/include/lustre/lustre_fid.h | 353 +++++++++++++++++++++ > > >>>>>> .../lustre/lustre/include/lustre/lustre_ostid.h | 233 ++++++++++++++ > > >>>>> > > >>>>> Can you make a lustre "uapi" directory so we can see which files you > > >>>>> really want to be UAPI and which you don't as time goes on? > > I said that ^^^ > > > >>>> Where do you want them placed? In uapi/linux/lustre or uapi/lustre. Does > > >>>> it matter to you? The below was to forth coming UAPI headers which from > > >>>> your response you seem okay with in general. > > >>> > > >>> How many .h files are there going to be? It's just a single filesystem, > > >>> shouldn't you just need a single file? If so, how about > > >>> drivers/staging/lustre/include/uapi/lustre.h > > >>> ? > > >>> > > >>> If you really need multiple .h files, put them all in the same uapi/ > > >>> directory with a lustre_ prefix, you don't need a whole subdir just for > > >>> yourself, right? > > >> > > >> We have 12 UAPI headers and yes they all begin with lustre_*. Okay I will > > >> create a driver/staging/lustre/include/uapi/linux directory and start > > >> moving headers there. > > > > > > 12 seems like a lot just for a single, tiny, filesystem :) > > > > > > But moving them all to a single directory will see where we can later > > > merge them together, sounds like a good plan. > > > > Greg, > > are you really adamantly against moving the Lustre headers into their own lustre/ > > subdirectory? > > I did not say that. > > Please, when responding to 5 month old email messages, get your quoting > correct... So this is coming from trying to understand the "merge them together" part. Some people reading this it implies all the headers would be eventually merged into one big header and placed into include/uapi/linux. We are getting to the point where some sites are migrating from the out of tree branch to this client. This also means they will be moving external open source userland applications shortly. If we expose UAPI headers that are completely different that it breaks their tools users will dump this client and go back to the out source tree. We really like to avoid that.