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: [lustre-devel] [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.
WARNING: multiple messages have this Message-ID (diff)
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: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-19 18:07 [lustre-devel] [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6 James Simmons
2016-08-19 18:07 ` James Simmons
2016-08-19 18:07 ` [lustre-devel] [PATCH 1/7] staging: lustre: lmv: implement lmv version of read_page James Simmons
2016-08-19 18:07 ` James Simmons
2016-08-19 18:07 ` [lustre-devel] [PATCH 2/7] staging: lustre: llite: move dir cache to MDC layer James Simmons
2016-08-19 18:07 ` James Simmons
2016-08-19 18:07 ` [lustre-devel] [PATCH 3/7] staging: lustre: obd: remove unused lmv_readpages()/mdc_readpage() James Simmons
2016-08-19 18:07 ` James Simmons
2016-08-19 18:07 ` [lustre-devel] [PATCH 4/7] staging: lustre: mdt: add OBD_CONNECT_DIR_STRIPE flag James Simmons
2016-08-19 18:07 ` James Simmons
2016-08-19 18:07 ` [lustre-devel] [PATCH 5/7] staging: lustre: obd: remove dead code James Simmons
2016-08-19 18:07 ` James Simmons
2016-08-19 18:07 ` [lustre-devel] [PATCH 6/7] staging: lustre: obd: decruft md_enqueue() and md_intent_lock() James Simmons
2016-08-19 18:07 ` James Simmons
2016-08-19 18:07 ` [lustre-devel] [PATCH 7/7] staging: lustre: update version to 2.5.99 James Simmons
2016-08-19 18:07 ` James Simmons
2016-08-19 18:39 ` [lustre-devel] [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6 Joe Perches
2016-08-19 18:39 ` Joe Perches
2016-08-19 19:44 ` [lustre-devel] " James Simmons
2016-08-19 19:44 ` James Simmons
2016-08-19 20:01 ` Joe Perches [this message]
2016-08-19 20:01 ` Joe Perches
2016-08-22 17:41 ` [lustre-devel] " James Simmons
2016-08-22 17:41 ` James Simmons
2016-08-22 17:55 ` [lustre-devel] " Joe Perches
2016-08-22 17:55 ` Joe Perches
2016-08-22 20:38 ` [lustre-devel] " Greg Kroah-Hartman
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.