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
2014-05-08T01:13:29Z

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