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
On Sun, Apr 08, 2001 at 09:47:06AM -0500, Marvin Stodolsky wrote:
> 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
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.
> 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
> Russell King wrote:
>
> On Sun, Apr 08, 2001 at 09:47:06AM -0500, Marvin Stodolsky wrote:
> > 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]>,
Marvin Stodolsky <[email protected]> wrote:
>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.
Miquel van Smoorenburg wrote:
> .. 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]>,
Jamie Lokier <[email protected]> wrote:
>Miquel van Smoorenburg wrote:
>> .. 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
--- linux-2.2.19.orig/Makefile Mon Apr 9 13:01:37 2001
+++ linux-2.2.19/Makefile Mon Apr 9 13:20:21 2001
@@ -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.
Miquel van Smoorenburg wrote:
> >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:
>
> [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.
> -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.
> +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
In article <[email protected]> you write:
>In article <[email protected]>,
>Marvin Stodolsky <[email protected]> wrote:
>>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.
Ahhhh. Not again.
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...
>
>Mike.
richard.
-----------------------------------------------------------------------
Richard Offer Technical Lead, Trust Technology.
"Specialization is for insects"
__________________________________________http://reality.sgi.com/offer/
-----------------------------------------------------------------------
Richard Offer Technical Lead, Trust Technology.
"Specialization is for insects"
__________________________________________http://reality.sgi.com/offer/
richard offer wrote:
> 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
* $ from [email protected] at "10-Apr: 4:08pm" | sed "1,$s/^/* /"
*
*
* richard offer wrote:
* > 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.
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.
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.
*
* -- Jamie
*
richard.
-----------------------------------------------------------------------
Richard Offer Technical Lead, Trust Technology.
"Specialization is for insects"
__________________________________________http://reality.sgi.com/offer/
richard offer wrote:
> * > 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.
>
> 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.
> 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
* $ from [email protected] at "10-Apr: 6:42pm" | sed "1,$s/^/* /"
*
*
* richard offer wrote:
* > * > 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.
* >
* > 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.
What if your application contains some user code and a kernel module ?
Want an obvious example ? X.
*
* > 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.
s/should/shouldn't/
*
* -- Jamie
*
richard.
-----------------------------------------------------------------------
Richard Offer Technical Lead, Trust Technology.
"Specialization is for insects"
__________________________________________http://reality.sgi.com/offer/
richard offer wrote:
> 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