On Tue, May 06, 2014 at 02:18:55AM -0500, xfs@xxxxxxxxxxx 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
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:
And check it out. The head is here:
6579dd8 libxfs: provide extern include file
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 :)
Description: Digital signature