From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751046AbdA3AJx (ORCPT ); Sun, 29 Jan 2017 19:09:53 -0500 Received: from casper.infradead.org ([85.118.1.10]:33986 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750828AbdA3AJt (ORCPT ); Sun, 29 Jan 2017 19:09:49 -0500 Date: Mon, 30 Jan 2017 00:09:26 +0000 (GMT) From: James Simmons To: Greg Kroah-Hartman cc: devel@driverdev.osuosl.org, Oleg Drokin , Andreas Dilger , Linux Kernel Mailing List , Lustre Development List Subject: Re: [PATCH] staging: lustre: headers: potential UAPI headers In-Reply-To: <20170121092459.GA29138@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> 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-20170130_000926_939066_88612BB7 X-CRM114-Status: GOOD ( 28.75 ) 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, 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? > > > > > > > > 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 :) I bet several lustre sys admins find this funny. Lustre exposes a lot of functionality to the applications to help them best optimize their behavior. That extra complexity can make admins and even normal users head spin!!! > But moving them all to a single directory will see where we can later > merge them together, sounds like a good plan. That would be one big header that would be constantly change. BTW we also have a few headers for LNet as well. One of them is lnetst.h which is for the LNet testing utility. It would be strange to merge a network simulation api into what standard users would use. Lets see once the work is done. I'm discussing currently with Intel developers the path forward on this work but it show be done in the near future.