* build -->/usr/src/linux @ 2001-04-08 14:47 ` Marvin Stodolsky 2001-04-08 15:16 ` Russell King 0 siblings, 1 reply; 13+ messages in thread From: Marvin Stodolsky @ 2001-04-08 14:47 UTC (permalink / raw) To: kaos, linux-kernel MODULE SUPPORT [GENERAL], KMOD P: Keith Owens M: kaos@ocs.com.au L: linux-kernel@vger.kernel.org ============================================ 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: build -->/usr/src/linux 2001-04-08 14:47 ` build -->/usr/src/linux Marvin Stodolsky @ 2001-04-08 15:16 ` Russell King 2001-04-08 17:30 ` Marvin Stodolsky 0 siblings, 1 reply; 13+ messages in thread From: Russell King @ 2001-04-08 15:16 UTC (permalink / raw) To: Marvin Stodolsky; +Cc: kaos, linux-kernel 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 (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: build -->/usr/src/linux 2001-04-08 15:16 ` Russell King @ 2001-04-08 17:30 ` Marvin Stodolsky 2001-04-08 21:49 ` Miquel van Smoorenburg 2001-04-09 23:01 ` richard offer 0 siblings, 2 replies; 13+ messages in thread From: Marvin Stodolsky @ 2001-04-08 17:30 UTC (permalink / raw) To: Russell King; +Cc: kaos, linux-kernel 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 (rmk@arm.linux.org.uk) The developer of ARM Linux > http://www.arm.linux.org.uk/personal/aboutme.html ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: build -->/usr/src/linux 2001-04-08 17:30 ` Marvin Stodolsky @ 2001-04-08 21:49 ` Miquel van Smoorenburg 2001-04-08 23:01 ` Jamie Lokier 2001-04-09 23:01 ` richard offer 1 sibling, 1 reply; 13+ messages in thread From: Miquel van Smoorenburg @ 2001-04-08 21:49 UTC (permalink / raw) To: linux-kernel In article <3AD0A029.C17C3EFC@rcn.com>, Marvin Stodolsky <stodolsk@rcn.com> 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: build -->/usr/src/linux 2001-04-08 21:49 ` Miquel van Smoorenburg @ 2001-04-08 23:01 ` Jamie Lokier 2001-04-09 11:29 ` Miquel van Smoorenburg 0 siblings, 1 reply; 13+ messages in thread From: Jamie Lokier @ 2001-04-08 23:01 UTC (permalink / raw) To: Miquel van Smoorenburg; +Cc: linux-kernel 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) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: build -->/usr/src/linux 2001-04-08 23:01 ` Jamie Lokier @ 2001-04-09 11:29 ` Miquel van Smoorenburg 2001-04-09 15:02 ` Jamie Lokier 0 siblings, 1 reply; 13+ messages in thread From: Miquel van Smoorenburg @ 2001-04-09 11:29 UTC (permalink / raw) To: linux-kernel In article <20010409010103.A16562@pcep-jamie.cern.ch>, Jamie Lokier <lk@tantalophile.demon.co.uk> 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: build -->/usr/src/linux 2001-04-09 11:29 ` Miquel van Smoorenburg @ 2001-04-09 15:02 ` Jamie Lokier 0 siblings, 0 replies; 13+ messages in thread From: Jamie Lokier @ 2001-04-09 15:02 UTC (permalink / raw) To: Miquel van Smoorenburg; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: build -->/usr/src/linux 2001-04-08 17:30 ` Marvin Stodolsky 2001-04-08 21:49 ` Miquel van Smoorenburg @ 2001-04-09 23:01 ` richard offer 2001-04-10 14:08 ` Jamie Lokier 1 sibling, 1 reply; 13+ messages in thread From: richard offer @ 2001-04-09 23:01 UTC (permalink / raw) To: linux-kernel In article <9aqmgo$8f6ol$1@fido.engr.sgi.com> you write: >In article <3AD0A029.C17C3EFC@rcn.com>, >Marvin Stodolsky <stodolsk@rcn.com> 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: build -->/usr/src/linux 2001-04-09 23:01 ` richard offer @ 2001-04-10 14:08 ` Jamie Lokier 2001-04-10 16:36 ` richard offer 0 siblings, 1 reply; 13+ messages in thread From: Jamie Lokier @ 2001-04-10 14:08 UTC (permalink / raw) To: richard offer; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: build -->/usr/src/linux 2001-04-10 14:08 ` Jamie Lokier @ 2001-04-10 16:36 ` richard offer 2001-04-10 16:42 ` Jamie Lokier 0 siblings, 1 reply; 13+ messages in thread From: richard offer @ 2001-04-10 16:36 UTC (permalink / raw) To: Jamie Lokier; +Cc: linux-kernel * $ from lk@tantalophile.demon.co.uk 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: build -->/usr/src/linux 2001-04-10 16:36 ` richard offer @ 2001-04-10 16:42 ` Jamie Lokier 2001-04-10 16:52 ` richard offer 0 siblings, 1 reply; 13+ messages in thread From: Jamie Lokier @ 2001-04-10 16:42 UTC (permalink / raw) To: richard offer; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: build -->/usr/src/linux 2001-04-10 16:42 ` Jamie Lokier @ 2001-04-10 16:52 ` richard offer 2001-04-10 17:04 ` Jamie Lokier 0 siblings, 1 reply; 13+ messages in thread From: richard offer @ 2001-04-10 16:52 UTC (permalink / raw) To: Jamie Lokier; +Cc: linux-kernel * $ from lk@tantalophile.demon.co.uk 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: build -->/usr/src/linux 2001-04-10 16:52 ` richard offer @ 2001-04-10 17:04 ` Jamie Lokier 0 siblings, 0 replies; 13+ messages in thread From: Jamie Lokier @ 2001-04-10 17:04 UTC (permalink / raw) To: richard offer; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2001-04-10 17:05 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <9aqmgo$8f6ol$1@fido.engr.sgi.com>
2001-04-08 14:47 ` build -->/usr/src/linux Marvin Stodolsky
2001-04-08 15:16 ` Russell King
2001-04-08 17:30 ` Marvin Stodolsky
2001-04-08 21:49 ` Miquel van Smoorenburg
2001-04-08 23:01 ` Jamie Lokier
2001-04-09 11:29 ` Miquel van Smoorenburg
2001-04-09 15:02 ` Jamie Lokier
2001-04-09 23:01 ` richard offer
2001-04-10 14:08 ` Jamie Lokier
2001-04-10 16:36 ` richard offer
2001-04-10 16:42 ` Jamie Lokier
2001-04-10 16:52 ` richard offer
2001-04-10 17:04 ` Jamie Lokier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox