Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1467862

Re: [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

> 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.

I didn't expect this to be requested at this time. I thought this would be 
addressed just before we left staging. I had to ponder the impact of
this change since this affects our userland utilities as well. Moving
the staging/lustre/lustre/include/* to include/linux/lustre is pretty
straight forward for the internal kernel headers.

The issues is that we still have entanglement issues with some of our uapi 
headers with internals of the kernel leaking to userland. I can push the 
cleanups we have so far but its not complete. Its close but not yet 
their. The other issue is I see some of our uapi headers for the upstream
client got nuked i.e userland  ifdefs got remove, so they are useless for 
userland now. Besides that is the impact on our userland utilities. 
Currently we expect our lustre uapi headers to be in /usr/include/lustre.
I noticed for uapi headers their is a mapping of

include/uapi/XXX -> /usr/include/XXX

This would mean that instead of the lustre api being moved to 

include/uapi/linux/lustre 

they would need to be instead in

include/uapi/lustre

Would that be acceptable? If not I guess we could add userland wrappers in 
/usr/include/lustre that point to the uapi headers. In any case we have to 
figure out something for our utilities. The same goes for LNet. We tend to 
use /usr/include/lnet/XXX. Is inclue/uapi/lnet acceptable. Also the few 
libcfs headers we use in userland needs to find a new home. 

This Wednsday we have a lustre community conference call were we discuss
upstream issues. This will need to be discussed.  

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH 0/7] staging: lustre: last missing patches for lustre 2.6 James Simmons <jsimmons@infradead.org> - 2016-08-19 20:10 +0200
  [PATCH 7/7] staging: lustre: update version to 2.5.99 James Simmons <jsimmons@infradead.org> - 2016-08-19 20:10 +0200
  [PATCH 2/7] staging: lustre: llite: move dir cache to MDC layer James Simmons <jsimmons@infradead.org> - 2016-08-19 20:10 +0200
  [PATCH 5/7] staging: lustre: obd: remove dead code James Simmons <jsimmons@infradead.org> - 2016-08-19 20:10 +0200
  [PATCH 3/7] staging: lustre: obd: remove unused lmv_readpages()/mdc_readpage() James Simmons <jsimmons@infradead.org> - 2016-08-19 20:10 +0200
  [PATCH 1/7] staging: lustre: lmv: implement lmv version of read_page James Simmons <jsimmons@infradead.org> - 2016-08-19 20:10 +0200
  [PATCH 4/7] staging: lustre: mdt: add OBD_CONNECT_DIR_STRIPE flag James Simmons <jsimmons@infradead.org> - 2016-08-19 20:10 +0200
  [PATCH 6/7] staging: lustre: obd: decruft md_enqueue() and md_intent_lock() James Simmons <jsimmons@infradead.org> - 2016-08-19 20:10 +0200
  Re: [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6 Joe Perches <joe@perches.com> - 2016-08-19 20:40 +0200
    Re: [PATCH 0/7] staging: lustre: last missing patches for lustre  2.6 James Simmons <jsimmons@infradead.org> - 2016-08-19 21:50 +0200
      Re: [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6 Joe Perches <joe@perches.com> - 2016-08-19 22:10 +0200
        Re: [PATCH 0/7] staging: lustre: last missing patches for lustre  2.6 James Simmons <jsimmons@infradead.org> - 2016-08-22 19:50 +0200
          Re: [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6 Joe Perches <joe@perches.com> - 2016-08-22 20:00 +0200
            Re: [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6 Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-22 22:40 +0200

csiph-web