build -->/usr/src/linux
MODULE SUPPORT [GENERAL], KMOD
P: Keith Owens M: [email protected] L: [email protected]
============================================
Though I've done some rational searching through the Documetation, an explanation hasn't manifested, as to why there has appeared in the
2.4.nn ??????:
# ls -l /lib/modules/2.4.3/ total 24 lrwxrwxrwx 1 root root ??????? 20 Apr 2 17:00 build -> /usr/src/linux-2.4.3 drwxr-xr-x 6 root root 1024 Apr 2 17:00 kernel -rw-r--r-- 1 root root 4725 Apr 8 08:06 modules.dep -rw-r--r-- 1 root root 31 Apr 8 08:06 modules.generic_string -rw-r--r-- 1 root root 4388 Apr 8 08:06 modules.isapnpmap -rw-r--r-- 1 root root 29 Apr 8 08:06 modules.parportmap -rw-r--r-- 1 root root 8723 Apr 8 08:06 modules.pcimap -rw-r--r-- 1 root root 1317 Apr 8 08:06 modules.usbmap lrwxrwxrwx 1 root root 35 Apr 2 17:05 pcmcia -> /lib/modules/2.4.3-oldpcmcia/pcmcia
-----------
Could someone enlighten me? What is it necessary for?
It's presence has required some gymnastics, per below, during module installation for the Winmodem driver, ltmodem.o requiring a subsequent "depmod -a"
MarvS
===========================================================
from the module install script ./ltinst
# To avoid non-relevant complaint noise that would be generated during
# depmod -a within update-modules
# under 2.4.nn kernels due to the symbolic Link # /lib/modules/2.4.nn/build --> /usr/src/linux # if kernel-source "make clean" is run betweem build_module & # ltinst (install ltmodem.o in the /lib/modules/ tree) # The Link is moved to /tmp and after "update-modules" is restored. if [ -L /lib/modules/$SYS/build ]; then mv /lib/modules/$SYS/build /tmp fi
# Updating module dependancies
if [ -f /etc/modutils/aliases ]; then
update-modules
else
depmod -a
fi
# Restoring build link if any
if [ -L /tmp/build ]; then
mv /tmp/build /lib/modules/$SYS/
fi
Quoted 3 lines · Marvin Stodolsky
It's presence has required some gymnastics, per below, during module installation for the Winmodem driver, ltmodem.o requiring a subsequent "depmod -a"
You need to update your modutils package - there have been a number of important bug fixes, including some which allow it to work properly with 2.4 kernels.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 2 lines · richard offer
What if your application contains some user code and a kernel module ? Want an obvious example ? X.
VMware is another. In such cases, they have to do the same as any other system-specific packages: guess, or ask the user. Autoconf apps prefer guessing; X uses Imake and would probably have the kernel source path hard-coded in an Imake template :-)
The discussions here have suggested ways for a third-party module package to guess how to install themselves, so that they will just work on most systems. /lib/modules/uname -r/build is the best anyone's come up with so far, and it does just work on "plain old" 2.4 systems. /usr/src/linux-uname -r is the next best.
This fails in certain cases such as cross-compiling, when the kernel isn't living in /usr/src or its not configured, and when it's not the running kernel.
But then, this is true of userspace too. Build an app on a Red Hat system, don't be surprised to find it fails to run on a Debian.
When cross-compiling a userspace app, you have to explicitly tell the package how to build, libraries to use etc. whether by command line flags or editing the source. That's the joy of cross-compiling. /usr/lib doesn't contain the right libraries, but it's ok for apps to look there _unless_ you say otherwise.
Same goes for kernel modules. /lib/modules/uname -r/build doesn't contain the right files when cross-compiling, but it's ok for module packages to look there _unless_ you say otherwise.
-- Jamie
Russell
Thanks for responding. But I would still like to understand what the functionality is of the build --> /usr/src/linuc. Is it dispensable, once the module tree has been installed?
Incidentally, per below, my own modutils is current, though some of the folks using our ltmodem.o compiler/installer kits may indeed need to update.
Quoted 3 lines
You need to update your modutils package - there have been a number of important bug fixes, including some which allow it to work properly with 2.4 kernels.
# insmod -V insmod version 2.4.2 # grep " # " /usr/src/linux-2.4.3/Documentation/Changes o Gnu C 2.91.66 # gcc --version o Gnu make 3.77 # make --version o binutils 2.9.1.0.25 # ld -v o util-linux 2.10o # fdformat --version o modutils 2.4.2 # insmod -V etc.
MarvS
Quoted 14 lines
Russell King wrote:
Quoted 3 lines · Marvin Stodolsky
It's presence has required some gymnastics, per below, during module installation for the Winmodem driver, ltmodem.o requiring a subsequent "depmod -a"
You need to update your modutils package - there have been a number of important bug fixes, including some which allow it to work properly with 2.4 kernels.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
In article <[email protected]>,
Quoted 3 lines · Marvin Stodolsky
Thanks for responding. But I would still like to understand what the functionality is of the build -->
/usr/src/linuc. Is it dispensable, once the module tree has been installed?
It's needed for modules that are distributed sperately, so that they can use cc -I /lib/modules/uname -r/build/include
Or even
l=`pwd` cd /lib/modules/`uname -r`/build make $l/module.o
.. but there should be a cleaner way to get at the CFLAGS used to compile the kernel.
Mike.
Quoted 2 lines · Miquel van Smoorenburg
.. but there should be a cleaner way to get at the CFLAGS used to compile the kernel.
There is a way though I'd not call it clean. Here is an extract from the Makefile I am using for separately-distributed modules. It should work with kernels 2.0 to 2.4, all supported architectures.
include $(KERNEL_SOURCE)/.config
CPPFLAGS := -DMODULE -D__KERNEL__ -nostdinc -I$(KERNEL_SOURCE)/include CPPFLAGS += -I$(shell gcc -print-file-name=include)
CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
AFLAGS := -D__ASSEMBLY__ $(CPPFLAGS)
# For older kernels.
ifneq (,$(strip $(shell grep '^[ ]*SMP[ ]*:\?=[ ]*[^ ]' $(KERNEL_SOURCE)/Makefile)))CONFIG_SMP=y
endif
ifdef CONFIG_SMP
CFLAGS += -D__SMP__
AFLAGS += -D__SMP__
endif
include $(KERNEL_SOURCE)/arch/$(ARCH)/Makefile
CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi)
In article <[email protected]>,
Quoted 5 lines · Jamie Lokier
Quoted 2 lines · Miquel van Smoorenburg
.. but there should be a cleaner way to get at the CFLAGS used to compile the kernel.
There is a way though I'd not call it clean. Here is an extract from
Do you think something like this is the correct approach? If it was part of the official kernel you could write a Makefile like this:
KSRC = /lib/modules/uname -r/build
include $(KSRC)/include/config.mak
CFLAGS := $(CFLAGS) $(MODFLAGS)
module.c: module.h
Makefile +28 -1
@@ -325,7 +325,8 @@ MODFLAGS += -DMODVERSIONS -include $(HPATH)/linux/modversions.h endif -modules: include/config/MARKER $(patsubst %, _mod_%, $(SUBDIRS)) +modules: include/config/MARKER $(patsubst %, _mod_%, $(SUBDIRS)) \ + include/linux/config.mak $(patsubst %, _mod_%, $(SUBDIRS)) : include/linux/version.h $(MAKE) -C $(patsubst _mod_%, %, $@) CFLAGS="$(CFLAGS) $(MODFLAGS)" MAKING_MODULES=1 modules
@@ -380,6 +381,31 @@ @exit 1 endif +include/linux/config.mak: ./Makefile + @echo "VERSION = $(VERSION)" > .mak + @echo "PATCHLEVEL = $(PATCHLEVEL)" >> .mak + @echo "SUBLEVEL = $(SUBLEVEL)" >> .mak + @echo "EXTRAVERSION = $(EXTRAVERSION)" >> .mak + @echo "ARCH = $(ARCH)" >> .mak + @echo "HOSTCC = $(HOSTCC)" >> .mak + @echo "HOSTCFLAGS = $(HOSTCFLAGS)" >> .mak + @echo "CROSS_COMPILE = $(CROSS_COMPILE)" >> .mak + @echo "AS = $(AS)" >> .mak + @echo "LD = $(LD)" >> .mak + @echo "CC = $(CC)" >> .mak + @echo "CPP = $(CPP)" >> .mak + @echo "AR = $(AR)" >> .mak + @echo "NM = $(NM)" >> .mak + @echo "STRIP = $(STRIP)" >> .mak + @echo "OBJCOPY = $(OBJCOPY)" >> .mak + @echo "OBJDUMP = $(OBJDUMP)" >> .mak + @echo "MAKE = $(MAKE)" >> .mak + @echo "GENKSYMS = $(GENKSYMS)" >> .mak + @echo "CFLAGS = $(CFLAGS)" >> .mak + @echo "AFLAGS = $(AFLAGS)" >> .mak + @echo "MODFLAGS = $(MODFLAGS)" >> .mak + @mv -f .mak $@ + clean: archclean rm -f kernel/ksyms.lst include/linux/compile.h rm -f core `find . -name '*.[oas]' ! \( -regex '.*lxdialog/.*' \
@@ -398,6 +424,7 @@ mrproper: clean archmrproper rm -f include/linux/autoconf.h include/linux/version.h + rm -f include/linux/config.mak rm -f drivers/net/hamradio/soundmodem/sm_tbl_{afsk1200,afsk2666,fsk9600}.h rm -f drivers/net/hamradio/soundmodem/sm_tbl_{hapn4800,psk4800}.h rm -f drivers/net/hamradio/soundmodem/sm_tbl_{afsk2400_7,afsk2400_8}.h
Mike.
Quoted 6 lines · Miquel van Smoorenburg
Quoted 1 line
There is a way though I'd not call it clean. Here is an extract from
Do you think something like this is the correct approach? If it was part of the official kernel you could write a
Makefilelike this:[code to creake
/lib/modules/uname -r/config.mak
I agree with that idea in principle, although for quite a while something else is required, to deal with older kernels. You'll notice that my fragment greps for SMP from the kernel's Makefile: that is to deal with 2.2 kernels and isn't required for 2.4 kernels. This is not an issue if you only care about future-compatibility.
Fortunately, the file $(KERNEL_SOURCE)/arc/$(ARCH)/Makefile provides most of the variables like CFLAGS et al.
Unfortunately, determining ARCH is rather ugly. I copied the expression from the kernel's top level Makefile.
One more thing: some systems do not have a /lib/modules directory. On those systems it's good to hunt in /usr/src/linux.
Review
Quoted 3 lines
(quoted diff) +2
-1-modules: include/config/MARKER $(patsubst %, _mod_%, $(SUBDIRS)) +modules: include/config/MARKER $(patsubst %, _mod_%, $(SUBDIRS)) \ + include/linux/config.mak
The file needs to be created even if you don't do `make modules'. Some kernels will support third party modules, but don't actually have any modules of their own.
Quoted 1 line
+include/linux/config.mak: ./Makefile
This must depend on the configuration somehow. If the kernel's reconfigured, a new file needs to be created. For 2.2 kernels it must depend on whether SMP is defined too.
-- Jamie
Quoted 4 lines · richard offer
uname does not always provide useful information (cross compiling). Even if you're building the same ISA, you maybe in a chroot'ed environment.
Can we please not assume that everybody only ever builds native...
Nobody is assuming that. If you're hard enough to do a cross compile, you can build external modules using "make KERNEL_RELEASE=2.4.2 KERNEL_SOURCE=/home/jamie/cross_compiling/kernel ARCH=mips64" or whatever.
-- Jamie
Quoted 10 lines · richard offer
* > uname does not always provide useful information (cross compiling). Even
* > if you're building the same ISA, you maybe in a chroot'ed environment.
* >
* > Can we please not assume that everybody only ever builds native... *
* Nobody is assuming that. If you're hard enough to do a cross compile,
* you can build external modules using "make KERNEL_RELEASE=2.4.2
* KERNEL_SOURCE=/home/jamie/cross_compiling/kernel ARCH=mips64" or
* whatever.
Quoted 5 lines
Applications make that assumption all the time.
Yes, this is the kernel mail list, but applications use kernel services. By tacitly agreeing that you get the kernel headers from
/lib/modules/uname -r/build/include that's what people will code into their makefiles.
_Applications_ should not use kernel headers at all. For ioctls, they should ship with copies of the definitions they need. That's been made clear as crystal many times on this list, and it should be in the FAQ if it isn't already.
Quoted 5 lines
Saying "oh, but applications should do that" isn't much of a argument, as there isn't a better way of working out where a set of kernel headers are. And "oh but applications should be using
/usr/include/" doesn't cut it. There are times when you really do need to be able to build things outside of the kernel tree that are kernel specific.
Sorry, I don't understand your message.
Are you saying, for third-party kernel modules, "oh well, use uname -r", "don't use uname -r", "use something else" or "I don't have any suggestions"?
-- Jamie