From: Joe Perches <joe@perches.com>
To: James Simmons <jsimmons@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devel@driverdev.osuosl.org,
Andreas Dilger <andreas.dilger@intel.com>,
Oleg Drokin <oleg.drokin@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Lustre Development List <lustre-devel@lists.lustre.org>
Subject: Re: [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6
Date: Fri, 19 Aug 2016 13:01:45 -0700 [thread overview]
Message-ID: <1471636905.3893.40.camel@perches.com> (raw)
In-Reply-To: <alpine.LFD.2.20.1608192007420.7759@casper.infradead.org>
On Fri, 2016-08-19 at 20:44 +0100, James Simmons wrote:
> > 1: I'd like to see the lustre #include files separated into
> > only two internal/external directories akin to the
> > include/linux and include/uapi directories used by linux.
[]
> For the first question yes it is reasonable and developers
> have been working to cleanup and separate out the uapi headers
> from the normal kernel headers. For staging/lustre/lustre we
> have local headers *_internal.h which only matter for that
> particular subdirectory. The rest of the headers are all in
>
> staging/lustre/lustre/include/*
>
> In that directory we have the linux subdirectory. That has
> gone away in newer lustre versions so I would need to push
> the patch to remove it. The other directory
>
> staging/lustre/lustre/include/lustre/*
>
> contains all our uapi headers like lustre_user.h and lustre_idl.h.
> Well that is not entirely correct. We still have uapi headers
> like uapi_kernelcomm.h one directory up. It just if we change those
> I need to update our userland tools as well. I have a patch ready
> but I need to push it to our utility branch as well.
> The next lot is all the LNet/libcfs stuff. The good news for LNet
> the headers have been cleaned up so separating them out is easy.
> Well there can always be more improvements. Now libcfs is a bit
> messy. The libcfs/linux directory needs to be removed yet. Also
> libcfs_debug.h needs to broken up for uapi use.
>
> Thats the run down about where we are at for the headers. Also it
> gives you an idea where we are heading. So how do you need this
> layed out for what you want to do? Where do you want to place the
> headers?
Thanks.
I don't _need_ anything, but I think it'd be simpler to
have just 2 directories, one for lustre kernel stuff
and another for lustre uapi stuff.
That applies for LNet and libcfs #includes as well.
To me, ideally, there'd only be 2 #include directories
so that the only used #include styles could become:
#include <linux/lustre/foo.h>
and
#include <uapi/lustre/bar.h>
and that would work regardless of lustre's layout
in staging or elsewhere.
next prev parent reply other threads:[~2016-08-19 20:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-19 18:07 [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6 James Simmons
2016-08-19 18:07 ` [PATCH 1/7] staging: lustre: lmv: implement lmv version of read_page James Simmons
2016-08-19 18:07 ` [PATCH 2/7] staging: lustre: llite: move dir cache to MDC layer James Simmons
2016-08-19 18:07 ` [PATCH 3/7] staging: lustre: obd: remove unused lmv_readpages()/mdc_readpage() James Simmons
2016-08-19 18:07 ` [PATCH 4/7] staging: lustre: mdt: add OBD_CONNECT_DIR_STRIPE flag James Simmons
2016-08-19 18:07 ` [PATCH 5/7] staging: lustre: obd: remove dead code James Simmons
2016-08-19 18:07 ` [PATCH 6/7] staging: lustre: obd: decruft md_enqueue() and md_intent_lock() James Simmons
2016-08-19 18:07 ` [PATCH 7/7] staging: lustre: update version to 2.5.99 James Simmons
2016-08-19 18:39 ` [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6 Joe Perches
2016-08-19 19:44 ` James Simmons
2016-08-19 20:01 ` Joe Perches [this message]
2016-08-22 17:41 ` James Simmons
2016-08-22 17:55 ` Joe Perches
2016-08-22 20:38 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1471636905.3893.40.camel@perches.com \
--to=joe@perches.com \
--cc=andreas.dilger@intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=jsimmons@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lustre-devel@lists.lustre.org \
--cc=oleg.drokin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox