[XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8

[XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8

[xfs]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, xfs-libxfs-in-kernel-RFC has been created
        at  6579dd808ddf0ddc10e59e715dc8f2eb09705203 (commit)

- Log -----------------------------------------------------------------
commit 6579dd808ddf0ddc10e59e715dc8f2eb09705203
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue May 6 17:13:06 2014 +1000

    libxfs: provide extern include file
    
    There will be different include files for userspace and
    kernel versions of the library as userspace needs to stub out or
    provide it's own versions of kernel only functionality. The header
    file that external libxfs users will need to include is libxfs.h,
    and there will be different implementations for both user and kernel
    space.
    
    All external users of libxfs will include this header file, thereby
    eliminating the need for direct knowledge of the internal dependency
    structure of the libxfs code. This significantly reduces the
    complexity of including libxfs functioanlity into the kernel code,
    and brings it in line with the way libxfs is used in userspace.
    
    This also allows us to untangle some of the mess with kernel only
    header files including shared header files directly, but does come
    with one piece of baggage - the dependency that libxfs has on the
    kernel xfs_mount.h. We'll deal with that at a later time, though.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>

commit 5e51adf5d9bba8f91fb5a99551878781bcc392f9
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue May 6 16:23:33 2014 +1000

    libxfs: consolidate internal include files
    
    There will be different include files for userspace and
    kernel versions of the library as userspace needs to stub out or
    provide it's own versions of kernel only functionality, convert all
    the internal libxfs source code to use the same single header file
    infrastructure that userspace currently contains. This means all the
    C source files will be identical, and only the header file will need
    to change. Call this internal consolidated header file libxfs_int.h
    to discriminate it from any other kernel or userspace header file.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>

commit 612480ce6bf4f96535f766eb27eb1b360a5a0714
Author: Dave Chinner <david@fromorbit.com>
Date:   Tue May 6 14:55:30 2014 +1000

    libxfs: move source files
    
    Move all the source files that are shared with userspace into
    libxfs/include. This is done as one big chunk simpy to get it done
    quickly.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>

commit 22b8ea8e926ea378a1066174a02147b90caebc12
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue May 6 14:54:32 2014 +1000

    libxfs: move header files
    
    Move all the header files that are shared with userspace into
    libxfs/include. This is done as one big chunk simpy to get it done
    quickly.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>

commit 20c53cba45be9da5a49a19042ec151abbf4b365e
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue May 6 14:54:24 2014 +1000

    xfs: create libxfs infrastructure
    
    TO minimise the differences between kernel and userspace code,
    split the kernel code into the same structure as the userspace code.
    That is, the gneric core functionality of XFS is moved to a libxfs/
    directory and treat it as a layering barrier in the XFS code.
    
    This patch introduces the libxfs and libxfs/include directories,
    the build infrastructure and an initial source and header file to
    build. The libxfs/include directory will contain the header files
    that are needed to build libxfs - most of userspace does not care
    about the location of these header files as they are accessed
    indirectly. Hence keeping them inside libxfs makes it easy to track
    the changes and script the sync process as the directory structure
    will be identical.
    
    TO allow this changeover to occur in the kernel code, there are some
    temporary infrastructure in the makefiles to grab the header
    filesystem from both locations. Once all the files are moved,
    modifications will be made in the source code that will make the
    need for these include directives go away.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>

-----------------------------------------------------------------------


hooks/post-receive
-- 
XFS development tree

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

[RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Dave Chinner]

[-- Attachment #1.1: Type: text/plain, Size: 4142 bytes --]

On Tue, May 06, 2014 at 02:18:55AM -0500, xfs@oss.sgi.com wrote:
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "XFS development tree".
> 
> The branch, xfs-libxfs-in-kernel-RFC has been created
>         at  6579dd808ddf0ddc10e59e715dc8f2eb09705203 (commit)

No doubt you are all wondering what this is by now. :)

I spent a couple of hours doing what I'd been talking about for a
while now - converting the xfs kernel source tree to have a libxfs
abstraction. It's based on the current for-next branch, so it's
completely up-to-date.

The commits in this series move all the files used by userspace to:

	- fs/xfs/libxfs for .c and private.h files
	- fs/xfs/libxfs/include for public .h files

It converts all the libxfs includes to makes the userspace libxfs
includes (just a single #include) for both internal (libxfs_int.h)
and external (libxfs.h). These will not be shared with userspace;
userspace will provide it's own just like it does now.

The core idea around this code layout is that we can now extract all
the changes to the libxfs code in the kernel in a simple manner
(commit by commit or as a single aggregate patch), and apply it to
the userspace libxfs code with the right pathname filter to the
patch command. That's all a sync will require in future, and should
make it scriptable and easy for anyone to do. It means, ideally,
that we can do libxfs updates at the same time we do kernel updates
with almost no effort.

There's still a few little messy corners, but I'm seriously tempted
just to merge this into for-next right now because it's all good. :)"

[ Seriously, it removes almost a thousand #include lines from the
kernel code, requires almost no extra infrastructure in the kernel,
already has passed several full xfstests runs and will make our life
so much easier. ]

Things that need to be done:

	- xfs_dir2_priv.h is included in places that it shouldn't
	  be. Whatever those callers need from that header file
	  should be moved to xfs_dir2.h and into libxfs proper.
	- the Makefiles still have a little bit of messy include
	  rules (i.e. -I$(src) -I$(src)/libxfs/include) bit I can
	  live with that I think.
	- some of the libxfs header files have a dependency on
	  xfs_mount.h for things like inode cluster and directory
	  block sizes. These need to be untangled, but it's not a
	  critical issue right now.
	- xfs_vnode.h needs to die.
	- the kernel only header files that include libxfs header
	  files can now drop those includes.

Overall, though, this was surprisingly easy to do. All of the recent
header file consolidation and cleanup that we've done made this
pretty much a case of git mv of all the files and little bit of
infrastructure, and not much else...

I suspect the next thing that needs to be done is consolidate libxfs
and libxlog in userspace, and split the log recovery code in the
kernel and put the shared part into fs/xfs/libxfs.....

I've put it up as a git branch rather than patches, because nobody
wants me posting a patchset with a diffstat like this:

$ git diff --stat for-next..
....
164 files changed, 47250 insertions(+), 48036 deletions(-)

However, when you tell git to be smart about renames (i.e file
movement is ignored), the actual diffstat looks like this:

$ git diff --stat --summary -C -M for-next..
....
108 files changed, 291 insertions(+), 1077 deletions(-)

If you want to look at it, pull from this branch:

git://oss.sgi.com/xfs/xfs xfs-libxfs-in-kernel-RFC

And check it out. The head is here:

6579dd8 libxfs: provide extern include file

New Commits:

Dave Chinner (5):
      [20c53cb] xfs: create libxfs infrastructure
      [22b8ea8] libxfs: move header files
      [612480c] libxfs: move source files
      [5e51adf] libxfs: consolidate internal include files
      [6579dd8] libxfs: provide extern include file

Comments, flames, suggestions and beer all welcome :)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Christoph Hellwig]

I like this in general, but one major and one minor issue with
the include files:

 - headers that just include other headers are a bad idea in general.
   Either they are dependent enough that they should be merged, or
   they are not, in which case they shouldn't.

   In this case it seems like we should temporarily provide a
   xfs_mount.h stub in userspace, and just leave all the includes
   for things in libxfs.h as they were.  That doesn't preclude further
   merging of the headers into more sensible ones as we've started
   with the disk formats.
 
 - do we really need the separate include/ dir?  That always annoys
   me when editing code.  It makes sense for something that is a real
   public interface, which this is not.

Also is libxfs/ really the right name?  libxfs in userspace has quite
a bit more code than this, so maybe we should just called this "shared"
for the shared user/kernel code?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Christoph Hellwig]

Getting rid of the need for xfs_mount.h in xfs_ialloc.h xfs_da_format.h
should be simple:

 - inline xfs_make_iptr into the only caller
 - move xfs_icluster_size_fsb to xfs_ialloc.c and just provide a
   prototype for it.
 - the various conversion routines for the directory blocks really
   shouldn't be in xfs_da_format.h anyway as they don't define the
   format.  Just have some other header that requires a version of
   xfs_mount included first.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Dave Chinner]

On Tue, May 06, 2014 at 01:37:44AM -0700, Christoph Hellwig wrote:
> I like this in general, but one major and one minor issue with
> the include files:
> 
>  - headers that just include other headers are a bad idea in general.
>    Either they are dependent enough that they should be merged, or
>    they are not, in which case they shouldn't.
> 
>    In this case it seems like we should temporarily provide a
>    xfs_mount.h stub in userspace, and just leave all the includes
>    for things in libxfs.h as they were.  That doesn't preclude further
>    merging of the headers into more sensible ones as we've started
>    with the disk formats.

I did this because I'm sick of having to edit 50+ files whenever a
single header dependency changes. There are almost all cookie cutter
duplicates because of the dependencies - if it were code, we'd
factor it in an instant.  I just don't see why we should treat 50
copies of the same header includes any differently....

>  - do we really need the separate include/ dir?  That always annoys
>    me when editing code.  It makes sense for something that is a real
>    public interface, which this is not.

It's for simplicity of updates with the userspace code. Both
userspace and kernel need the same code layout, and userspace
currently has a separate include directory for all the header files
(and they get installed that way, too). If we want to change the
userspace source layout and commingle all the headers with the C
code, then that's a lot more work on the userspace side (i.e. it's
more than just pointing the include/xfs symlink to libxfs/include).

I don't mind which approach we take - it's trivial to rework the
patchset to place all the headers in the libxfs/ directory - I just
took the one that matched the current userspace infrastructure...

> Also is libxfs/ really the right name?  libxfs in userspace has quite
> a bit more code than this, so maybe we should just called this "shared"
> for the shared user/kernel code?

I'd like to have this kernel code define libxfs/, while in userspace
we separate out all the support code (i.e. libxfs/rdwr.c, etc) into
a different directory that builds the userspace libraries. i.e.
libxfs/ is a static object archive that is wrapped by the userspace
infrastructure, just like the kernel wraps it with infrastructure to
make it useful...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Dave Chinner]

On Tue, May 06, 2014 at 01:43:28AM -0700, Christoph Hellwig wrote:
> Getting rid of the need for xfs_mount.h in xfs_ialloc.h xfs_da_format.h
> should be simple:
> 
>  - inline xfs_make_iptr into the only caller
>  - move xfs_icluster_size_fsb to xfs_ialloc.c and just provide a
>    prototype for it.

Yeah, those are easy.

>  - the various conversion routines for the directory blocks really
>    shouldn't be in xfs_da_format.h anyway as they don't define the
>    format.  Just have some other header that requires a version of
>    xfs_mount included first.

Still has the same problem - the library code is dependent on an
externally defined struct xfs_mount. What needs to happen is the
directory code needs to define the structure that carries all the
precalculated geometry, and the struct mount use that structure to
store them. Then the directory code can use it's own structure
as the function argument, and the dependence on struct xfs_mount
goes away completely.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Brian Foster]

On Tue, May 06, 2014 at 05:59:05PM +1000, Dave Chinner wrote:
> On Tue, May 06, 2014 at 02:18:55AM -0500, xfs@oss.sgi.com wrote:
> > This is an automated email from the git hooks/post-receive script. It was
> > generated because a ref change was pushed to the repository containing
> > the project "XFS development tree".
> > 
> > The branch, xfs-libxfs-in-kernel-RFC has been created
> >         at  6579dd808ddf0ddc10e59e715dc8f2eb09705203 (commit)
> 
> No doubt you are all wondering what this is by now. :)
> 
> I spent a couple of hours doing what I'd been talking about for a
> while now - converting the xfs kernel source tree to have a libxfs
> abstraction. It's based on the current for-next branch, so it's
> completely up-to-date.
> 
> The commits in this series move all the files used by userspace to:
> 
> 	- fs/xfs/libxfs for .c and private.h files
> 	- fs/xfs/libxfs/include for public .h files
> 
> It converts all the libxfs includes to makes the userspace libxfs
> includes (just a single #include) for both internal (libxfs_int.h)
> and external (libxfs.h). These will not be shared with userspace;
> userspace will provide it's own just like it does now.
> 
> The core idea around this code layout is that we can now extract all
> the changes to the libxfs code in the kernel in a simple manner
> (commit by commit or as a single aggregate patch), and apply it to
> the userspace libxfs code with the right pathname filter to the
> patch command. That's all a sync will require in future, and should
> make it scriptable and easy for anyone to do. It means, ideally,
> that we can do libxfs updates at the same time we do kernel updates
> with almost no effort.
> 
> There's still a few little messy corners, but I'm seriously tempted
> just to merge this into for-next right now because it's all good. :)"
> 
> [ Seriously, it removes almost a thousand #include lines from the
> kernel code, requires almost no extra infrastructure in the kernel,
> already has passed several full xfstests runs and will make our life
> so much easier. ]
> 
> Things that need to be done:
> 
> 	- xfs_dir2_priv.h is included in places that it shouldn't
> 	  be. Whatever those callers need from that header file
> 	  should be moved to xfs_dir2.h and into libxfs proper.
> 	- the Makefiles still have a little bit of messy include
> 	  rules (i.e. -I$(src) -I$(src)/libxfs/include) bit I can
> 	  live with that I think.
> 	- some of the libxfs header files have a dependency on
> 	  xfs_mount.h for things like inode cluster and directory
> 	  block sizes. These need to be untangled, but it's not a
> 	  critical issue right now.
> 	- xfs_vnode.h needs to die.
> 	- the kernel only header files that include libxfs header
> 	  files can now drop those includes.
> 
> Overall, though, this was surprisingly easy to do. All of the recent
> header file consolidation and cleanup that we've done made this
> pretty much a case of git mv of all the files and little bit of
> infrastructure, and not much else...
> 
> I suspect the next thing that needs to be done is consolidate libxfs
> and libxlog in userspace, and split the log recovery code in the
> kernel and put the shared part into fs/xfs/libxfs.....
> 
> I've put it up as a git branch rather than patches, because nobody
> wants me posting a patchset with a diffstat like this:
> 
> $ git diff --stat for-next..
> ....
> 164 files changed, 47250 insertions(+), 48036 deletions(-)
> 
> However, when you tell git to be smart about renames (i.e file
> movement is ignored), the actual diffstat looks like this:
> 
> $ git diff --stat --summary -C -M for-next..
> ....
> 108 files changed, 291 insertions(+), 1077 deletions(-)
> 
> If you want to look at it, pull from this branch:
> 
> git://oss.sgi.com/xfs/xfs xfs-libxfs-in-kernel-RFC
> 
> And check it out. The head is here:
> 
> 6579dd8 libxfs: provide extern include file
> 

It looks like a nice cleanup to me from the perspective of maintaining
synchronization between kernel and userspace. I suppose it gets more
interesting if we want to consider libxfs as something potentially
externally consumable, particularly whether we have broken things out at
the right interfaces. This certainly gets the ball rolling in that
direction. I have no major objections given that this mostly looks like
a mechanical code restructure.

Note that the Makefile structure between the core and libxfs/ subdir
appears to be busted for module compiles. It attempts to create a
libxfs.ko and doesn't appear to create any real link dependency between
the logical modules:

...
WARNING: "__tracepoint_xfs_dir2_sf_create" [fs/xfs/libxfs/libxfs.ko]
undefined!
WARNING: "__tracepoint_xfs_da_root_join" [fs/xfs/libxfs/libxfs.ko]
undefined!
WARNING: "xfs_trans_mod_sb" [fs/xfs/libxfs/libxfs.ko] undefined!
WARNING: "xfs_extent_busy_insert" [fs/xfs/libxfs/libxfs.ko] undefined!
WARNING: "__tracepoint_xfs_dir2_sf_addname" [fs/xfs/libxfs/libxfs.ko]
undefined!
  CC      fs/xfs/xfs.mod.o
  CC      fs/xfs/libxfs/libxfs.mod.o
  LD [M]  fs/xfs/xfs.ko
  LD [M]  fs/xfs/libxfs/libxfs.ko

I played with it a bit but didn't get anywhere without just pulling the
source file dependency up into fs/xfs/Makefile. :/

Brian

> New Commits:
> 
> Dave Chinner (5):
>       [20c53cb] xfs: create libxfs infrastructure
>       [22b8ea8] libxfs: move header files
>       [612480c] libxfs: move source files
>       [5e51adf] libxfs: consolidate internal include files
>       [6579dd8] libxfs: provide extern include file
> 
> Comments, flames, suggestions and beer all welcome :)
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com



> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Dave Chinner]

On Wed, May 07, 2014 at 10:48:22AM -0400, Brian Foster wrote:
> On Tue, May 06, 2014 at 05:59:05PM +1000, Dave Chinner wrote:
> > On Tue, May 06, 2014 at 02:18:55AM -0500, xfs@oss.sgi.com wrote:
> > > This is an automated email from the git hooks/post-receive script. It was
> > > generated because a ref change was pushed to the repository containing
> > > the project "XFS development tree".
> > > 
> > > The branch, xfs-libxfs-in-kernel-RFC has been created
> > >         at  6579dd808ddf0ddc10e59e715dc8f2eb09705203 (commit)
> > 
> > No doubt you are all wondering what this is by now. :)
> > 
> > I spent a couple of hours doing what I'd been talking about for a
> > while now - converting the xfs kernel source tree to have a libxfs
> > abstraction. It's based on the current for-next branch, so it's
> > completely up-to-date.
> > 
> > The commits in this series move all the files used by userspace to:
> > 
> > 	- fs/xfs/libxfs for .c and private.h files
> > 	- fs/xfs/libxfs/include for public .h files
> > 
> > It converts all the libxfs includes to makes the userspace libxfs
> > includes (just a single #include) for both internal (libxfs_int.h)
> > and external (libxfs.h). These will not be shared with userspace;
> > userspace will provide it's own just like it does now.
> > 
> > The core idea around this code layout is that we can now extract all
> > the changes to the libxfs code in the kernel in a simple manner
> > (commit by commit or as a single aggregate patch), and apply it to
> > the userspace libxfs code with the right pathname filter to the
> > patch command. That's all a sync will require in future, and should
> > make it scriptable and easy for anyone to do. It means, ideally,
> > that we can do libxfs updates at the same time we do kernel updates
> > with almost no effort.
> > 
> > There's still a few little messy corners, but I'm seriously tempted
> > just to merge this into for-next right now because it's all good. :)"
> > 
> > [ Seriously, it removes almost a thousand #include lines from the
> > kernel code, requires almost no extra infrastructure in the kernel,
> > already has passed several full xfstests runs and will make our life
> > so much easier. ]
> > 
> > Things that need to be done:
> > 
> > 	- xfs_dir2_priv.h is included in places that it shouldn't
> > 	  be. Whatever those callers need from that header file
> > 	  should be moved to xfs_dir2.h and into libxfs proper.
> > 	- the Makefiles still have a little bit of messy include
> > 	  rules (i.e. -I$(src) -I$(src)/libxfs/include) bit I can
> > 	  live with that I think.
> > 	- some of the libxfs header files have a dependency on
> > 	  xfs_mount.h for things like inode cluster and directory
> > 	  block sizes. These need to be untangled, but it's not a
> > 	  critical issue right now.
> > 	- xfs_vnode.h needs to die.
> > 	- the kernel only header files that include libxfs header
> > 	  files can now drop those includes.
> > 
> > Overall, though, this was surprisingly easy to do. All of the recent
> > header file consolidation and cleanup that we've done made this
> > pretty much a case of git mv of all the files and little bit of
> > infrastructure, and not much else...
> > 
> > I suspect the next thing that needs to be done is consolidate libxfs
> > and libxlog in userspace, and split the log recovery code in the
> > kernel and put the shared part into fs/xfs/libxfs.....
> > 
> > I've put it up as a git branch rather than patches, because nobody
> > wants me posting a patchset with a diffstat like this:
> > 
> > $ git diff --stat for-next..
> > ....
> > 164 files changed, 47250 insertions(+), 48036 deletions(-)
> > 
> > However, when you tell git to be smart about renames (i.e file
> > movement is ignored), the actual diffstat looks like this:
> > 
> > $ git diff --stat --summary -C -M for-next..
> > ....
> > 108 files changed, 291 insertions(+), 1077 deletions(-)
> > 
> > If you want to look at it, pull from this branch:
> > 
> > git://oss.sgi.com/xfs/xfs xfs-libxfs-in-kernel-RFC
> > 
> > And check it out. The head is here:
> > 
> > 6579dd8 libxfs: provide extern include file
> > 
> 
> It looks like a nice cleanup to me from the perspective of maintaining
> synchronization between kernel and userspace. I suppose it gets more
> interesting if we want to consider libxfs as something potentially
> externally consumable, particularly whether we have broken things out at
> the right interfaces. This certainly gets the ball rolling in that
> direction. I have no major objections given that this mostly looks like
> a mechanical code restructure.

Yes, it is a mechanical code restructure. It's pretty straight
forward, the only thing that consumed any amount of time was the
include file changes.

> Note that the Makefile structure between the core and libxfs/ subdir
> appears to be busted for module compiles. It attempts to create a
> libxfs.ko and doesn't appear to create any real link dependency between
> the logical modules:

Ok, I hadn't tested that. I'll look into it.

> ...
> WARNING: "__tracepoint_xfs_dir2_sf_create" [fs/xfs/libxfs/libxfs.ko]
> undefined!
> WARNING: "__tracepoint_xfs_da_root_join" [fs/xfs/libxfs/libxfs.ko]
> undefined!
> WARNING: "xfs_trans_mod_sb" [fs/xfs/libxfs/libxfs.ko] undefined!
> WARNING: "xfs_extent_busy_insert" [fs/xfs/libxfs/libxfs.ko] undefined!
> WARNING: "__tracepoint_xfs_dir2_sf_addname" [fs/xfs/libxfs/libxfs.ko]
> undefined!

That tends to imply I didn't do the right thing with the tracing,
either.

>   CC      fs/xfs/xfs.mod.o
>   CC      fs/xfs/libxfs/libxfs.mod.o
>   LD [M]  fs/xfs/xfs.ko
>   LD [M]  fs/xfs/libxfs/libxfs.ko
> 
> I played with it a bit but didn't get anywhere without just pulling the
> source file dependency up into fs/xfs/Makefile. :/

I'll see what I can dig up.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Dave Chinner]

On Thu, May 08, 2014 at 08:47:55AM +1000, Dave Chinner wrote:
> On Wed, May 07, 2014 at 10:48:22AM -0400, Brian Foster wrote:
> > Note that the Makefile structure between the core and libxfs/ subdir
> > appears to be busted for module compiles. It attempts to create a
> > libxfs.ko and doesn't appear to create any real link dependency between
> > the logical modules:
> 
> Ok, I hadn't tested that. I'll look into it.
> 
> > ...
> > WARNING: "__tracepoint_xfs_dir2_sf_create" [fs/xfs/libxfs/libxfs.ko]
> > undefined!
> > WARNING: "__tracepoint_xfs_da_root_join" [fs/xfs/libxfs/libxfs.ko]
> > undefined!
> > WARNING: "xfs_trans_mod_sb" [fs/xfs/libxfs/libxfs.ko] undefined!
> > WARNING: "xfs_extent_busy_insert" [fs/xfs/libxfs/libxfs.ko] undefined!
> > WARNING: "__tracepoint_xfs_dir2_sf_addname" [fs/xfs/libxfs/libxfs.ko]
> > undefined!
> 
> That tends to imply I didn't do the right thing with the tracing,
> either.
> 
> >   CC      fs/xfs/xfs.mod.o
> >   CC      fs/xfs/libxfs/libxfs.mod.o
> >   LD [M]  fs/xfs/xfs.ko
> >   LD [M]  fs/xfs/libxfs/libxfs.ko
> > 
> > I played with it a bit but didn't get anywhere without just pulling the
> > source file dependency up into fs/xfs/Makefile. :/
> 
> I'll see what I can dig up.

Well, I can make use of "lib-y" to get around the "libxfs is built
as a module" problem:

....
  CC      fs/xfs/libxfs/xfs_sb.o
  CC      fs/xfs/libxfs/xfs_symlink_remote.o
  CC      fs/xfs/libxfs/xfs_trans_resv.o
  AR      fs/xfs/libxfs/lib.a

but then there is the issue of adding it as a link flag to the xfs
object itself. That involved a bit of a ld hack, but I have it
compiling as a module now. Patch below.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

libxfs: fix modular build

From: Dave Chinner <dchinner@redhat.com>

As reported by Brain Foster:

Note that the Makefile structure between the core and libxfs/ subdir
appears to be busted for module compiles. It attempts to create a
libxfs.ko and doesn't appear to create any real link dependency between
the logical modules:

...
WARNING: "__tracepoint_xfs_dir2_sf_create" [fs/xfs/libxfs/libxfs.ko]
undefined!
WARNING: "__tracepoint_xfs_da_root_join" [fs/xfs/libxfs/libxfs.ko]
undefined!
WARNING: "xfs_trans_mod_sb" [fs/xfs/libxfs/libxfs.ko] undefined!
WARNING: "xfs_extent_busy_insert" [fs/xfs/libxfs/libxfs.ko] undefined!
WARNING: "__tracepoint_xfs_dir2_sf_addname" [fs/xfs/libxfs/libxfs.ko]
undefined!
  CC      fs/xfs/xfs.mod.o
  CC      fs/xfs/libxfs/libxfs.mod.o
  LD [M]  fs/xfs/xfs.ko
  LD [M]  fs/xfs/libxfs/libxfs.ko

Fix it by converting libxfs to be a static library, and hack the
fs/xfs/xfs.o linker commands to include it directly and so
completely avoid the need for a libxfs.ko module until we have
sorted out all the circular dependency issues.

Reported-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
 fs/xfs/Makefile        | 22 +++++++++++++++++++---
 fs/xfs/libxfs/Makefile | 12 +++++++-----
 2 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/fs/xfs/Makefile b/fs/xfs/Makefile
index c520bff..726cfaa 100644
--- a/fs/xfs/Makefile
+++ b/fs/xfs/Makefile
@@ -20,10 +20,26 @@ ccflags-y += -I$(src)			# needed for trace events
 ccflags-y += -I$(src)/libxfs		# XXX: temporary!
 ccflags-y += -I$(src)/libxfs/include	# XXX: temporary!
 
-ccflags-$(CONFIG_XFS_DEBUG) += -g
+# libxfs should inheret this as well.
+subdir-ccflags-$(CONFIG_XFS_DEBUG) += -g
 
-obj-$(CONFIG_XFS_FS)		+= xfs.o \
-				   libxfs/
+# When building as a module, we don't want a separate libxfs.ko,
+# so we specifically have to link the libxfs.o object into the
+# xfs.ko module. Hence we need to tell LD to do this appropriately.
+#ldflags-y += -L$(obj)/libxfs -l:libxfs.o
+#
+# The use of --start-group without --endgroup here is a bit of a hack
+# to avoid needing to use symbol exports and real modules.
+# This works around the fact that ldflags-y is included on the linker command
+# line before all the object files built in this directory, and hence
+# it drops all the unreferenced symbols from libxfs. i.e. all the ones that
+# that xfs.ko module actually requires. The lack of an "--end-group" varaible
+# means LD considers all object files on the command line for recursive object
+# searching and hence solves the specification order problem.
+ldflags-y += --start-group $(obj)/libxfs/lib.a
+
+obj-$(CONFIG_XFS_FS)		+= libxfs/ \
+				   xfs.o
 
 # this one should be compiled first, as the tracing macros can easily blow up
 xfs-y				+= xfs_trace.o
diff --git a/fs/xfs/libxfs/Makefile b/fs/xfs/libxfs/Makefile
index e3de6df..b5f443b 100644
--- a/fs/xfs/libxfs/Makefile
+++ b/fs/xfs/libxfs/Makefile
@@ -8,11 +8,13 @@
 ccflags-y += -I$(src)/..
 ccflags-y += -I$(src)/include -Werror		# needed for trace events
 
-ccflags-$(CONFIG_XFS_DEBUG) += -g
+# Use the lib-X directives rather than obj-X so that this doesn't get built as a
+# module itself and have unresolvable circular dependencies with the xfs module.
+# This means the xfs module needs to specifically link libxfs/lib.a because we
+# are not adding fs/xfs/libxfs to the libs-y built-in library search
+# directories. A bit hacky, but it seems to work as desired for modular builds.
 
-obj-$(CONFIG_XFS_FS)	+= libxfs.o
-
-libxfs-y		+= xfs_alloc.o \
+lib-(CONFIG_XFS_FS)	+= xfs_alloc.o \
 			   xfs_alloc_btree.o \
 			   xfs_attr.o \
 			   xfs_attr_leaf.o \
@@ -38,4 +40,4 @@ libxfs-y		+= xfs_alloc.o \
 			   xfs_symlink_remote.o \
 			   xfs_trans_resv.o
 
-libxfs-$(CONFIG_XFS_RT)	+= xfs_rtbitmap.o
+lib-$(CONFIG_XFS_RT)	+= xfs_rtbitmap.o

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Brian Foster]

[-- Attachment #1: Type: text/plain, Size: 7424 bytes --]

On Thu, May 08, 2014 at 11:12:56AM +1000, Dave Chinner wrote:
> On Thu, May 08, 2014 at 08:47:55AM +1000, Dave Chinner wrote:
> > On Wed, May 07, 2014 at 10:48:22AM -0400, Brian Foster wrote:
> > > Note that the Makefile structure between the core and libxfs/ subdir
> > > appears to be busted for module compiles. It attempts to create a
> > > libxfs.ko and doesn't appear to create any real link dependency between
> > > the logical modules:
> > 
> > Ok, I hadn't tested that. I'll look into it.
> > 
> > > ...
> > > WARNING: "__tracepoint_xfs_dir2_sf_create" [fs/xfs/libxfs/libxfs.ko]
> > > undefined!
> > > WARNING: "__tracepoint_xfs_da_root_join" [fs/xfs/libxfs/libxfs.ko]
> > > undefined!
> > > WARNING: "xfs_trans_mod_sb" [fs/xfs/libxfs/libxfs.ko] undefined!
> > > WARNING: "xfs_extent_busy_insert" [fs/xfs/libxfs/libxfs.ko] undefined!
> > > WARNING: "__tracepoint_xfs_dir2_sf_addname" [fs/xfs/libxfs/libxfs.ko]
> > > undefined!
> > 
> > That tends to imply I didn't do the right thing with the tracing,
> > either.
> > 
> > >   CC      fs/xfs/xfs.mod.o
> > >   CC      fs/xfs/libxfs/libxfs.mod.o
> > >   LD [M]  fs/xfs/xfs.ko
> > >   LD [M]  fs/xfs/libxfs/libxfs.ko
> > > 
> > > I played with it a bit but didn't get anywhere without just pulling the
> > > source file dependency up into fs/xfs/Makefile. :/
> > 
> > I'll see what I can dig up.
> 
> Well, I can make use of "lib-y" to get around the "libxfs is built
> as a module" problem:
> 
> ....
>   CC      fs/xfs/libxfs/xfs_sb.o
>   CC      fs/xfs/libxfs/xfs_symlink_remote.o
>   CC      fs/xfs/libxfs/xfs_trans_resv.o
>   AR      fs/xfs/libxfs/lib.a
> 
> but then there is the issue of adding it as a link flag to the xfs
> object itself. That involved a bit of a ld hack, but I have it
> compiling as a module now. Patch below.
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 
> libxfs: fix modular build
> 
> From: Dave Chinner <dchinner@redhat.com>
> 
> As reported by Brain Foster:
> 
> Note that the Makefile structure between the core and libxfs/ subdir
> appears to be busted for module compiles. It attempts to create a
> libxfs.ko and doesn't appear to create any real link dependency between
> the logical modules:
> 
> ...
> WARNING: "__tracepoint_xfs_dir2_sf_create" [fs/xfs/libxfs/libxfs.ko]
> undefined!
> WARNING: "__tracepoint_xfs_da_root_join" [fs/xfs/libxfs/libxfs.ko]
> undefined!
> WARNING: "xfs_trans_mod_sb" [fs/xfs/libxfs/libxfs.ko] undefined!
> WARNING: "xfs_extent_busy_insert" [fs/xfs/libxfs/libxfs.ko] undefined!
> WARNING: "__tracepoint_xfs_dir2_sf_addname" [fs/xfs/libxfs/libxfs.ko]
> undefined!
>   CC      fs/xfs/xfs.mod.o
>   CC      fs/xfs/libxfs/libxfs.mod.o
>   LD [M]  fs/xfs/xfs.ko
>   LD [M]  fs/xfs/libxfs/libxfs.ko
> 
> Fix it by converting libxfs to be a static library, and hack the
> fs/xfs/xfs.o linker commands to include it directly and so
> completely avoid the need for a libxfs.ko module until we have
> sorted out all the circular dependency issues.
> 
> Reported-by: Brian Foster <bfoster@redhat.com>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---
>  fs/xfs/Makefile        | 22 +++++++++++++++++++---
>  fs/xfs/libxfs/Makefile | 12 +++++++-----
>  2 files changed, 26 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/xfs/Makefile b/fs/xfs/Makefile
> index c520bff..726cfaa 100644
> --- a/fs/xfs/Makefile
> +++ b/fs/xfs/Makefile
> @@ -20,10 +20,26 @@ ccflags-y += -I$(src)			# needed for trace events
>  ccflags-y += -I$(src)/libxfs		# XXX: temporary!
>  ccflags-y += -I$(src)/libxfs/include	# XXX: temporary!
>  
> -ccflags-$(CONFIG_XFS_DEBUG) += -g
> +# libxfs should inheret this as well.
> +subdir-ccflags-$(CONFIG_XFS_DEBUG) += -g
>  
> -obj-$(CONFIG_XFS_FS)		+= xfs.o \
> -				   libxfs/
> +# When building as a module, we don't want a separate libxfs.ko,
> +# so we specifically have to link the libxfs.o object into the
> +# xfs.ko module. Hence we need to tell LD to do this appropriately.
> +#ldflags-y += -L$(obj)/libxfs -l:libxfs.o
> +#
> +# The use of --start-group without --endgroup here is a bit of a hack
> +# to avoid needing to use symbol exports and real modules.
> +# This works around the fact that ldflags-y is included on the linker command
> +# line before all the object files built in this directory, and hence
> +# it drops all the unreferenced symbols from libxfs. i.e. all the ones that
> +# that xfs.ko module actually requires. The lack of an "--end-group" varaible
> +# means LD considers all object files on the command line for recursive object
> +# searching and hence solves the specification order problem.
> +ldflags-y += --start-group $(obj)/libxfs/lib.a
> +
> +obj-$(CONFIG_XFS_FS)		+= libxfs/ \
> +				   xfs.o
>  
>  # this one should be compiled first, as the tracing macros can easily blow up
>  xfs-y				+= xfs_trace.o
> diff --git a/fs/xfs/libxfs/Makefile b/fs/xfs/libxfs/Makefile
> index e3de6df..b5f443b 100644
> --- a/fs/xfs/libxfs/Makefile
> +++ b/fs/xfs/libxfs/Makefile
> @@ -8,11 +8,13 @@
>  ccflags-y += -I$(src)/..
>  ccflags-y += -I$(src)/include -Werror		# needed for trace events
>  
> -ccflags-$(CONFIG_XFS_DEBUG) += -g
> +# Use the lib-X directives rather than obj-X so that this doesn't get built as a
> +# module itself and have unresolvable circular dependencies with the xfs module.
> +# This means the xfs module needs to specifically link libxfs/lib.a because we
> +# are not adding fs/xfs/libxfs to the libs-y built-in library search
> +# directories. A bit hacky, but it seems to work as desired for modular builds.
>  
> -obj-$(CONFIG_XFS_FS)	+= libxfs.o
> -
> -libxfs-y		+= xfs_alloc.o \
> +lib-(CONFIG_XFS_FS)	+= xfs_alloc.o \

Missing a $ here...

Adding that, the single threaded build still breaks for me. E.g.,

- rm -rf fs/xfs
- git checkout -- .
- make

...
  CC [M]  fs/xfs/xfs_qm.o
  CC [M]  fs/xfs/xfs_quotaops.o
  CC [M]  fs/xfs/xfs_acl.o
  CC [M]  fs/xfs/xfs_stats.o
  CC [M]  fs/xfs/xfs_sysctl.o
  CC [M]  fs/xfs/xfs_ioctl32.o
  LD [M]  fs/xfs/xfs.o
ld: cannot find fs/xfs/libxfs/lib.a: No such file or directory
make[2]: *** [fs/xfs/xfs.o] Error 1
make[1]: *** [fs/xfs] Error 2
make: *** [fs] Error 2

If I repeat and make -j 4 a couple times I can get around it (i.e., it
may still create lib.a and fail, so a repeat run will work). I suspect
this just means the dependency isn't quite right. It looks like it maybe
tries to link the current object (xfs.o) before moving on to the
subdir, but the subdir dependency creates the lib.a.

It seems to work if I use this in xfs/Makefile:

obj-y                           += libxfs/
obj-$(CONFIG_XFS_FS)            += xfs.o

... rather than putting both deps under the CONFIG conditional, but I
think that might make the libxfs bits built-in:

...
  CC      fs/xfs/libxfs/xfs_symlink_remote.o
  CC      fs/xfs/libxfs/xfs_trans_resv.o
  AR      fs/xfs/libxfs/lib.a
  LD      fs/xfs/built-in.o
  CC [M]  fs/xfs/xfs_trace.o
...

FWIW, the attached diff shows what I mean by pulling things into
fs/xfs/Makefile. This works Ok for me. It's not the pure separation we
probably want to have, but perhaps good enough for now and avoids weird
build infrastructure hacks.

Brian

>  			   xfs_alloc_btree.o \
>  			   xfs_attr.o \
>  			   xfs_attr_leaf.o \
> @@ -38,4 +40,4 @@ libxfs-y		+= xfs_alloc.o \
>  			   xfs_symlink_remote.o \
>  			   xfs_trans_resv.o
>  
> -libxfs-$(CONFIG_XFS_RT)	+= xfs_rtbitmap.o
> +lib-$(CONFIG_XFS_RT)	+= xfs_rtbitmap.o

[-- Attachment #2: xfs_make.diff --]
[-- Type: text/plain, Size: 1715 bytes --]

diff --git a/fs/xfs/Makefile b/fs/xfs/Makefile
index 726cfaa..70082c7 100644
--- a/fs/xfs/Makefile
+++ b/fs/xfs/Makefile
@@ -36,10 +36,9 @@ subdir-ccflags-$(CONFIG_XFS_DEBUG) += -g
 # that xfs.ko module actually requires. The lack of an "--end-group" varaible
 # means LD considers all object files on the command line for recursive object
 # searching and hence solves the specification order problem.
-ldflags-y += --start-group $(obj)/libxfs/lib.a
+#ldflags-y += --start-group $(obj)/libxfs/lib.a
 
-obj-$(CONFIG_XFS_FS)		+= libxfs/ \
-				   xfs.o
+obj-$(CONFIG_XFS_FS)		+= xfs.o
 
 # this one should be compiled first, as the tracing macros can easily blow up
 xfs-y				+= xfs_trace.o
@@ -105,3 +104,32 @@ xfs-$(CONFIG_XFS_POSIX_ACL)	+= xfs_acl.o
 xfs-$(CONFIG_PROC_FS)		+= xfs_stats.o
 xfs-$(CONFIG_SYSCTL)		+= xfs_sysctl.o
 xfs-$(CONFIG_COMPAT)		+= xfs_ioctl32.o
+
+# libxfs
+xfs-y			+= libxfs/xfs_alloc.o \
+			   libxfs/xfs_alloc_btree.o \
+			   libxfs/xfs_attr.o \
+			   libxfs/xfs_attr_leaf.o \
+			   libxfs/xfs_attr_remote.o \
+			   libxfs/xfs_bmap.o \
+			   libxfs/xfs_bmap_btree.o \
+			   libxfs/xfs_btree.o \
+			   libxfs/xfs_da_btree.o \
+			   libxfs/xfs_da_format.o \
+			   libxfs/xfs_dir2.o \
+			   libxfs/xfs_dir2_block.o \
+			   libxfs/xfs_dir2_data.o \
+			   libxfs/xfs_dir2_leaf.o \
+			   libxfs/xfs_dir2_node.o \
+			   libxfs/xfs_dir2_sf.o \
+			   libxfs/xfs_dquot_buf.o \
+			   libxfs/xfs_ialloc.o \
+			   libxfs/xfs_ialloc_btree.o \
+			   libxfs/xfs_inode_fork.o \
+			   libxfs/xfs_inode_buf.o \
+			   libxfs/xfs_log_rlimit.o \
+			   libxfs/xfs_sb.o \
+			   libxfs/xfs_symlink_remote.o \
+			   libxfs/xfs_trans_resv.o
+
+xfs-$(CONFIG_XFS_RT)	+= libxfs/xfs_rtbitmap.o

[-- Attachment #3: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Christoph Hellwig]

On Thu, May 08, 2014 at 08:02:28AM -0400, Brian Foster wrote:
> Missing a $ here...
> 
> Adding that, the single threaded build still breaks for me. E.g.,
> 
> - rm -rf fs/xfs
> - git checkout -- .
> - make

The kernel build systems doesn't support building a single module from
multiple makefiles.  Take a look how to handle a subdirectory in the
older XFS versions that still had that linux-2.6 subdirectory, it just
pulls the files in the subdirectory in from the main makefile, which
requires some tiny hacks for the include path.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Brian Foster]

On Thu, May 08, 2014 at 05:54:05AM -0700, Christoph Hellwig wrote:
> On Thu, May 08, 2014 at 08:02:28AM -0400, Brian Foster wrote:
> > Missing a $ here...
> > 
> > Adding that, the single threaded build still breaks for me. E.g.,
> > 
> > - rm -rf fs/xfs
> > - git checkout -- .
> > - make
> 
> The kernel build systems doesn't support building a single module from
> multiple makefiles.  Take a look how to handle a subdirectory in the
> older XFS versions that still had that linux-2.6 subdirectory, it just
> pulls the files in the subdirectory in from the main makefile, which
> requires some tiny hacks for the include path.
> 

Good point, I was looking around for some example of this and didn't see
anything obvious, but didn't think to look back to that. Indeed it does
just reference the files in the subdirectory... thanks.

Brian

> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Dave Chinner]

On Thu, May 08, 2014 at 09:45:20AM -0400, Brian Foster wrote:
> On Thu, May 08, 2014 at 05:54:05AM -0700, Christoph Hellwig wrote:
> > On Thu, May 08, 2014 at 08:02:28AM -0400, Brian Foster wrote:
> > > Missing a $ here...
> > > 
> > > Adding that, the single threaded build still breaks for me. E.g.,
> > > 
> > > - rm -rf fs/xfs
> > > - git checkout -- .
> > > - make
> > 
> > The kernel build systems doesn't support building a single module from
> > multiple makefiles.  Take a look how to handle a subdirectory in the
> > older XFS versions that still had that linux-2.6 subdirectory, it just
> > pulls the files in the subdirectory in from the main makefile, which
> > requires some tiny hacks for the include path.
> > 
> 
> Good point, I was looking around for some example of this and didn't see
> anything obvious, but didn't think to look back to that. Indeed it does
> just reference the files in the subdirectory... thanks.

I haven't looked at that, but I'm assuming that it is just a

-include libxfs/Makefile

directive rather than using:

obj-y += libxfs/

If that's all it takes, then I'll rebase the patch on that....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Christoph Hellwig]

On Fri, May 09, 2014 at 07:21:20AM +1000, Dave Chinner wrote:
> I haven't looked at that, but I'm assuming that it is just a
> 
> -include libxfs/Makefile
> 
> directive rather than using:
> 
> obj-y += libxfs/
> 
> If that's all it takes, then I'll rebase the patch on that....


The -include line could work, but I'd rather do it like we did in
the old days and have a single makefile.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Christoph Hellwig]

On Tue, May 06, 2014 at 07:00:56PM +1000, Dave Chinner wrote:
> I did this because I'm sick of having to edit 50+ files whenever a
> single header dependency changes. There are almost all cookie cutter
> duplicates because of the dependencies - if it were code, we'd
> factor it in an instant.  I just don't see why we should treat 50
> copies of the same header includes any differently....

So let's factor it out by fixing our header mess like I started
with the format headers.  That's the real fix instead of encoding
that mess by wrapping it.

> >  - do we really need the separate include/ dir?  That always annoys
> >    me when editing code.  It makes sense for something that is a real
> >    public interface, which this is not.
> 
> It's for simplicity of updates with the userspace code. Both
> userspace and kernel need the same code layout, and userspace
> currently has a separate include directory for all the header files
> (and they get installed that way, too). If we want to change the
> userspace source layout and commingle all the headers with the C
> code, then that's a lot more work on the userspace side (i.e. it's
> more than just pointing the include/xfs symlink to libxfs/include).
> 
> I don't mind which approach we take - it's trivial to rework the
> patchset to place all the headers in the libxfs/ directory - I just
> took the one that matched the current userspace infrastructure...

The only ones installed are xfs_fs.h and xfs_types.h.  The first one
is special.  I'd really prefer to to make a major mess of the layout
for this.  In fact I don't even really see the need for a subdirectory
just to share the files.

> 
> > Also is libxfs/ really the right name?  libxfs in userspace has quite
> > a bit more code than this, so maybe we should just called this "shared"
> > for the shared user/kernel code?
> 
> I'd like to have this kernel code define libxfs/, while in userspace
> we separate out all the support code (i.e. libxfs/rdwr.c, etc) into
> a different directory that builds the userspace libraries. i.e.
> libxfs/ is a static object archive that is wrapped by the userspace
> infrastructure, just like the kernel wraps it with infrastructure to
> make it useful...

Well, libxfs is the whole think in userspace.  So even if you absolutely
want to stick to a messy hiecharical layout we could at least condens it
to:

fs/xfs/shared
fs/xfs/include

	in the kernel

libxfs/shared
libxfs/include

	in userspace

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [RFC] libxfs kernel infrastructure (was [XFS updates] XFS development tree branch, xfs-libxfs-in-kernel-RFC, created. xfs-for-linus-3.15-rc2-52-g6579dd8)

[Dave Chinner]

On Fri, May 09, 2014 at 12:29:42AM -0700, Christoph Hellwig wrote:
> On Tue, May 06, 2014 at 07:00:56PM +1000, Dave Chinner wrote:
> > I did this because I'm sick of having to edit 50+ files whenever a
> > single header dependency changes. There are almost all cookie cutter
> > duplicates because of the dependencies - if it were code, we'd
> > factor it in an instant.  I just don't see why we should treat 50
> > copies of the same header includes any differently....
> 
> So let's factor it out by fixing our header mess like I started
> with the format headers.  That's the real fix instead of encoding
> that mess by wrapping it.

Ok, I'm not exactly sure what the layout you envisiage is. Can you
explain it so that I've got some idea of how much more work is
involved in getting to that?

> > >  - do we really need the separate include/ dir?  That always annoys
> > >    me when editing code.  It makes sense for something that is a real
> > >    public interface, which this is not.
> > 
> > It's for simplicity of updates with the userspace code. Both
> > userspace and kernel need the same code layout, and userspace
> > currently has a separate include directory for all the header files
> > (and they get installed that way, too). If we want to change the
> > userspace source layout and commingle all the headers with the C
> > code, then that's a lot more work on the userspace side (i.e. it's
> > more than just pointing the include/xfs symlink to libxfs/include).
> > 
> > I don't mind which approach we take - it's trivial to rework the
> > patchset to place all the headers in the libxfs/ directory - I just
> > took the one that matched the current userspace infrastructure...
> 
> The only ones installed are xfs_fs.h and xfs_types.h.  The first one
> is special.  I'd really prefer to to make a major mess of the layout
> for this.  In fact I don't even really see the need for a subdirectory
> just to share the files.

I'd prefer to have a subdir layout the same across both code bases
simply because it makes management of the synchronisation process so
much easier. The overhead of synchronisation is one of the reasons
it doesn't get done as often as it should, and that's a problem we
really need to solve. same directory heirarchy in user and kernel
land makes it simple to script...

> > > Also is libxfs/ really the right name?  libxfs in userspace has quite
> > > a bit more code than this, so maybe we should just called this "shared"
> > > for the shared user/kernel code?
> > 
> > I'd like to have this kernel code define libxfs/, while in userspace
> > we separate out all the support code (i.e. libxfs/rdwr.c, etc) into
> > a different directory that builds the userspace libraries. i.e.
> > libxfs/ is a static object archive that is wrapped by the userspace
> > infrastructure, just like the kernel wraps it with infrastructure to
> > make it useful...
> 
> Well, libxfs is the whole think in userspace.  So even if you absolutely
> want to stick to a messy hiecharical layout we could at least condens it
> to:
> 
> fs/xfs/shared
> fs/xfs/include
> 
> 	in the kernel
> 
> libxfs/shared
> libxfs/include
> 
> 	in userspace

Realistically, if we're going to change the entire libxfs code
layout in userspace as well, we may as well just change userspace to
handle all the exported libxfs include files directly from the
libxfs directory, and keep it as a flat directory.

Like I said, I just did the libxfs/include to make it easy to retain
the existing userspace structure, so if we aren't going to do that
then we don't need a separate libxfs/include. I think I'll head down
that path (modify both kernel and userland structure) so that we
don't end up with deep heirarchies...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs