Skip to contentSkip to conversation

Symlinks for building external modules

PATCH In review Andreas Gruenbacher 4 participants 9 messages Jun 3, 2004 – Jun 5, 2004 Kbuild

lore
Share & tools
lore

Andreas Gruenbacher

author
#0 lore raw

PATCH 1/1 Symlinks for building external modules

Hi Sam,

modules not in the kernel source tree need to locate both the source tree and the object tree (O=). Currently, the /lib/modules/$(uname -r)/build symlink is the only reference we have; it historically points to the source tree from 2.4 times. The following patch changes this as follows (this is what we have in the current SUSE tree now):

	/lib/modules/$(uname -r)/source ==> source tree
	/lib/modules/$(uname -r)/build ==> object tree

Both links are required for building external modules with:

	make -C /lib/modules/$(uname -r)/source \
		O=/lib/modules/$(uname -r)/build \
		M=$(pwd)
Makefile +3 -2
Index: linux-2.6.7-rc2/Makefile
===================================================================
@@ -732,9 +732,10 @@ _modinst_:
 		sleep 1; \
 	fi
 	@rm -rf $(MODLIB)/kernel
-	@rm -f $(MODLIB)/build
+	@rm -f $(MODLIB)/{source,build}
 	@mkdir -p $(MODLIB)/kernel
-	@ln -s $(TOPDIR) $(MODLIB)/build
+	@ln -s $(srctree) $(MODLIB)/source
+	@ln -s $(objtree) $(MODLIB)/build
 	$(Q)$(MAKE) -rR -f $(srctree)/scripts/Makefile.modinst
 
 # If System.map exists, run depmod.  This deliberately does not have a

Thanks,

Signature · 2 lines
Andreas Gruenbacher <[email protected]>
SUSE Labs, SUSE LINUX AG
#1 lore raw
Quoted 11 lines · Andreas Gruenbacher

Hi Sam,

modules not in the kernel source tree need to locate both the source tree and the object tree (O=). Currently, the /lib/modules/$(uname -r)/build symlink is the only reference we have; it historically points to the source tree from 2.4 times. The following patch changes this as follows (this is what we have in the current SUSE tree now):

	/lib/modules/$(uname -r)/source ==> source tree
	/lib/modules/$(uname -r)/build ==> object tree

This will break the building of all external modules until they are updated, and break updated modules building against older kernels unless they check the kernel version in the makefiles.. I suggest leaving the 'build' link as is, and using a difference name for the build directory, perhaps 'object'. This might look confusing, so we could have a 'source' link as well and remove the 'build' link when most external modules have been updated.

Signature · 2 lines
Måns Rullgård
[email protected]
#2 lore raw
Quoted 14 lines · Måns Rullgård
Quoted 11 lines · Andreas Gruenbacher

Hi Sam,

modules not in the kernel source tree need to locate both the source tree and the object tree (O=). Currently, the /lib/modules/$(uname -r)/build symlink is the only reference we have; it historically points to the source tree from 2.4 times. The following patch changes this as follows (this is what we have in the current SUSE tree now):

	/lib/modules/$(uname -r)/source ==> source tree
	/lib/modules/$(uname -r)/build ==> object tree
Quoted 7 lines

This will break the building of all external modules until they are updated, and break updated modules building against older kernels unless they check the kernel version in the makefiles.. I suggest leaving the 'build' link as is, and using a difference name for the build directory, perhaps 'object'. This might look confusing, so we could have a 'source' link as well and remove the 'build' link when most external modules have been updated.

The existing external modules are anyway broken when using separate directories for source and output directories. So noting lost here. In the case where the kernel is build in the traditional way the build and source tree will point to the same place.

So I do not see this patch breaking existing setups, but I see external modules not being prepared for separate build and source directories.

Patch looks good to me, and I will forward to Andrew soon.

Sam

#3 lore raw
Quoted 23 lines · Sam Ravnborg
Quoted 14 lines · Måns Rullgård
Quoted 11 lines · Andreas Gruenbacher

Hi Sam,

modules not in the kernel source tree need to locate both the source tree and the object tree (O=). Currently, the /lib/modules/$(uname -r)/build symlink is the only reference we have; it historically points to the source tree from 2.4 times. The following patch changes this as follows (this is what we have in the current SUSE tree now):

	/lib/modules/$(uname -r)/source ==> source tree
	/lib/modules/$(uname -r)/build ==> object tree
Quoted 7 lines

This will break the building of all external modules until they are updated, and break updated modules building against older kernels unless they check the kernel version in the makefiles.. I suggest leaving the 'build' link as is, and using a difference name for the build directory, perhaps 'object'. This might look confusing, so we could have a 'source' link as well and remove the 'build' link when most external modules have been updated.

Quoted 2 lines

The existing external modules are anyway broken when using separate directories for source and output directories.

They work fine if you pass O=/some/path on the make command line.

Quoted 3 lines

So noting lost here. In the case where the kernel is build in the traditional way the build and source tree will point to the same place.

True.

Quoted 5 lines

So I do not see this patch breaking existing setups, but I see external modules not being prepared for separate build and source directories.

Patch looks good to me, and I will forward to Andrew soon.

I'll just have to go fix my kernel modules then.

Signature · 2 lines
Måns Rullgård
[email protected]
#4 lore raw
In reply to Sam Ravnborg
Quoted 20 lines · Sam Ravnborg
Quoted 11 lines · Måns Rullgård
Quoted 9 lines · Andreas Gruenbacher

modules not in the kernel source tree need to locate both the source tree and the object tree (O=). Currently, the /lib/modules/$(uname -r)/build symlink is the only reference we have; it historically points to the source tree from 2.4 times. The following patch changes this as follows (this is what we have in the current SUSE tree now):

    /lib/modules/$(uname -r)/source ==> source tree
    /lib/modules/$(uname -r)/build ==> object tree
Quoted 7 lines

This will break the building of all external modules until they are updated, and break updated modules building against older kernels unless they check the kernel version in the makefiles.. I suggest leaving the 'build' link as is, and using a difference name for the build directory, perhaps 'object'. This might look confusing, so we could have a 'source' link as well and remove the 'build' link when most external modules have been updated.

Quoted 2 lines

The existing external modules are anyway broken when using separate directories for source and output directories. So noting lost here.

Wrong! Existing external modules build fine when specified an object directory.

Quoted 6 lines

In the case where the kernel is build in the traditional way the build and source tree will point to the same place.

So I do not see this patch breaking existing setups, but I see external modules not being prepared for separate build and source directories.

How long have you recommended building external modules like this:

make -C /lib/modules/uname -r/build modules SUBDIRS=pwd
or
make -C /lib/modules/uname -r/build modules M=pwd

Now they all have to be changed to:

make -C /lib/modules/uname -r/source modules SUBDIRS=pwd
or
make -C /lib/modules/uname -r/source modules M=pwd

And the worst part is that modules that have to support old and new kernel versions have to first detect which method to use, and select method that applies to that paricular kernel version.

Quoted 1 line

Patch looks good to me, and I will forward to Andrew soon.

That patch only breaks stuff. Please use the 'object' symlink suggested by Måns Rullgård. That does not break anything.

Signature · 1 line
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD
#5 lore raw
Quoted 7 lines · Jari Ruusu

How long have you recommended building external modules like this:

make -C /lib/modules/uname -r/build modules SUBDIRS=pwd
or
make -C /lib/modules/uname -r/build modules M=pwd

Quoted 5 lines

Now they all have to be changed to:

make -C /lib/modules/uname -r/source modules SUBDIRS=pwd
or
make -C /lib/modules/uname -r/source modules M=pwd

That would not work either.
You need to tell kbuild both where to find the source and the output files. So you have to specify both -C ... and O=... KERNEL=/lib/modules/uname -r
make -C $KERNEL/source O=$KERNEL/build M=pwd

There is no way to do the proposed chang and be backward compatible when the kernel is build using seperate output directories.

Think of the following situation
/usr/src/linux-2.6.6-xx/ <= kernel src

/lib/modules/linux-2.6.6-xx-smp/build/ <= output files (or a symlink to them) /lib/modules/linux-2.6.6-xx-smp/source/ <= symlink to kernel src

/lib/modules/linux-2.6.6-xx-up/build/ <= output files (or symlink) /lib/modules/linux-2.6.6-xx-up/source/ <= symlink to kernel src

/lib/modules/linux-2.6.6-xx-4g/build/ <= output files (or symlink) /lib/modules/linux-2.6.6-xx-4g/source/ <= symlink to kernel src

Notice they all share the _same_ kernel src.
We just have three different .config files.

If there is a way to be backward compatible with
this feature please demonstrate it.

Plese note that the patch Andreas made did not break existing setups if a seperate output directory was not used. The only effect would be an additional symlink to the same dir. (build and source would be links to the same dir).

Andreas - please expalin why you want build to be a symlink, and not the directory used when actually building the kernel.

Sam

#6 lore raw
Quoted 14 lines · Sam Ravnborg
Quoted 7 lines · Jari Ruusu

How long have you recommended building external modules like this:

make -C /lib/modules/uname -r/build modules SUBDIRS=pwd
or
make -C /lib/modules/uname -r/build modules M=pwd

Quoted 5 lines

Now they all have to be changed to:

make -C /lib/modules/uname -r/source modules SUBDIRS=pwd
or
make -C /lib/modules/uname -r/source modules M=pwd

Quoted 8 lines

That would not work either.
You need to tell kbuild both where to find the source and the output files. So you have to specify both -C ... and O=... KERNEL=/lib/modules/uname -r
make -C $KERNEL/source O=$KERNEL/build M=pwd

There is no way to do the proposed chang and be backward compatible when the kernel is build using seperate output directories.

There are many external module packages that assume /lib/modules/uname -r/build to contain the kernel sources. These can be built with

make O=/some/path

If the content of /lib/modules/uname -r/build changes this will no longer work.

Quoted 18 lines

Think of the following situation
/usr/src/linux-2.6.6-xx/ <= kernel src

/lib/modules/linux-2.6.6-xx-smp/build/ <= output files (or a symlink to them) /lib/modules/linux-2.6.6-xx-smp/source/ <= symlink to kernel src

/lib/modules/linux-2.6.6-xx-up/build/ <= output files (or symlink) /lib/modules/linux-2.6.6-xx-up/source/ <= symlink to kernel src

/lib/modules/linux-2.6.6-xx-4g/build/ <= output files (or symlink) /lib/modules/linux-2.6.6-xx-4g/source/ <= symlink to kernel src

Notice they all share the _same_ kernel src.
We just have three different .config files.

If there is a way to be backward compatible with
this feature please demonstrate it.

Quoted 7 lines

Plese note that the patch Andreas made did not break existing setups if a seperate output directory was not used. The only effect would be an additional symlink to the same dir. (build and source would be links to the same dir).

Andreas - please expalin why you want build to be a symlink, and not the directory used when actually building the kernel.

I can't speak for Andreas, but I prefer to keep my root filesystem as clean as possible. Often it's mounted read-only.

Signature · 2 lines
Måns Rullgård
[email protected]
author
#7 lore raw
Quoted 6 lines · Måns Rullgård
Quoted 2 lines · Sam Ravnborg

Andreas - please expalin why you want build to be a symlink, and not the directory used when actually building the kernel.

I can't speak for Andreas, but I prefer to keep my root filesystem as clean as possible. Often it's mounted read-only.

Either way would work, but I prefer to have the actual files below /usr/src. The /lib directory is meant for files required during boot, whereas /usr may be mounted later. If we want to allow both possibilities, we probably want to add the following check:

Makefile +2 -1
Index: linux-2.6.7-rc2/Makefile
===================================================================
@@ -735,7 +735,8 @@ _modinst_:
        @rm -f $(MODLIB)/{source,build}
        @mkdir -p $(MODLIB)/kernel
        @ln -s $(srctree) $(MODLIB)/source
-       @ln -s $(objtree) $(MODLIB)/build
+       @[ $(objtree) -ef  $(MODLIB)/build ] \
+               || ln -s $(objtree) $(MODLIB)/build
        $(Q)$(MAKE) -rR -f $(srctree)/scripts/Makefile.modinst

Next, we may want to add a Makefile to the output directory so that external modules will build the same way they did before, without specifying the source tree separately:

Makefile +9 -1
Index: linux-2.6.7-rc2/Makefile
===================================================================
@@ -125,11 +125,19 @@ ifeq ($(skip-makefile),)
 # but instead _all depend on modules
 .PHONY: all
 ifeq ($(KBUILD_EXTMOD),)
-_all: all
+_all: $(objtree)/Makefile all
 else
 _all: modules
 endif
 
+.PHONY: $(objtree)/Makefile
+$(objtree)/Makefile:
+       $(Q)if [ ! $(srctree) -ef $(objtree) ]; then \
+               ( echo "modules modules_install clean:" ; \
+                 echo -e "\t\$$(MAKE) -C $(srctree) \$$@ O=\$$(CURDIR)" \
+               ) > $(objtree)/Makefile ; \
+       fi
+
 # Make sure we're not wasting cpu-cycles doing locale handling, yet do make
 # sure error messages appear in the user-desired language
 ifdef LC_ALL

Cheers,

Signature · 2 lines
Andreas Gruenbacher <[email protected]>
SUSE Labs, SUSE LINUX AG
#8 lore raw
In reply to Sam Ravnborg
Quoted 13 lines · Sam Ravnborg
Quoted 11 lines · Jari Ruusu

How long have you recommended building external modules like this:

make -C /lib/modules/uname -r/build modules SUBDIRS=pwd
or
make -C /lib/modules/uname -r/build modules M=pwd

Now they all have to be changed to:

make -C /lib/modules/uname -r/source modules SUBDIRS=pwd
or
make -C /lib/modules/uname -r/source modules M=pwd

Quoted 8 lines

That would not work either.
You need to tell kbuild both where to find the source and the output files. So you have to specify both -C ... and O=... KERNEL=/lib/modules/uname -r
make -C $KERNEL/source O=$KERNEL/build M=pwd

There is no way to do the proposed chang and be backward compatible when the kernel is build using seperate output directories.

What I and Måns Rullgård are saying is this: A symlink to object directory is missing. The fix is to add the damn symlink. However, breaking symlink to source directory at the same time is unacceptable.

In other words:
build -> Symlink to kernel sources and build machinery, Makefiles and
scripts. No change here.
object -> Symlink to separate object tree. This is new.

Existing functionality when using separate source and object directories is that only the 'build' symlink exists, and that points to kernel build machinery. And that 'build' symlink must stay that way.

Quoted 4 lines

Plese note that the patch Andreas made did not break existing setups if a seperate output directory was not used. The only effect would be an additional symlink to the same dir. (build and source would be links to the same dir).

All code that uses the 'build' symlink needs to be changed if Andreas' patch is merged to mainline. That is quite breakage.

Sam, you are wrong here. I hope you have enough balls to admit that instead of forcing everyone to deal with the proposed breakage.

Signature · 1 line
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD