Hi, I have currently following problem with batman-adv-kernelland and batmand- gateway:
Danial Baumann supports building of kernel modules against the current Debian kernel in sid with his linux-modules-extra-2.6 package. The module sources must only to support build over the kernel headers. It is done like that: /usr/bin/make -C /usr/src/linux-headers-2.6.29-1-amd64 M=/batman-adv/
So it calls the Makefile in /usr/src/linux-headers-2.6.29-1-amd64 to build the sources in /batman-adv/. This seems to be a quite common way to do the build. There are different problems with the way the current Makefiles of these modules are written.
First thing is that there is a Makefile.kbuild which is included with include $(PWD)/Makefile.kbuild This will not work in the current situation because the PWD is now /usr/src/linux-headers-2.6.29-1-amd64. Is this extra Makefile.kbuild really needed? The second problem is the check of KERNELPATH of Makefile. It will check if the sources of the current kernel is installed and quits if not (+ error message that someone should set the KERNELPATH variable). In the current situation we don't have the sources of the current kernel installed, but the kernel headers of another kernel are being used automatically. Wouldn't be following check
KERNELPATH ?= /lib/modules/$(shell uname -r)/build # sanity check: does KERNELPATH exist? ifeq ($(shell cd $(KERNELPATH) && pwd),) $(warning $(KERNELPATH) is missing, please set KERNELPATH) endif
ok too?
The batmand-gateway cannot be build for linux 2.6 if the current kernel is a 2.4.x. Isn't it possible to make the obj-m and batgat-objs assignment outside the check for the kernel version?
My current workaround is to install my own version of the Makefile in the debian package, but I ask myself if this is really needed or parts of it should also be changed upstream.
Best regards, Sven
Hi,
First thing is that there is a Makefile.kbuild which is included with include $(PWD)/Makefile.kbuild This will not work in the current situation because the PWD is now /usr/src/linux-headers-2.6.29-1-amd64. Is this extra Makefile.kbuild really needed?
the Makefile.kbuild was introduced to support OpenWRT better (OpenWRT uses the kbuild Makefile only and replaces the main Makefile with its own). Could we do the same with debian ?
KERNELPATH ?= /lib/modules/$(shell uname -r)/build # sanity check: does KERNELPATH exist? ifeq ($(shell cd $(KERNELPATH) && pwd),) $(warning $(KERNELPATH) is missing, please set KERNELPATH) endif
ok too?
Yes, I think its fine. I commited it.
The batmand-gateway cannot be build for linux 2.6 if the current kernel is a 2.4.x. Isn't it possible to make the obj-m and batgat-objs assignment outside the check for the kernel version?
I'm not so sure what you have in mind. Could you explain it further ?
My current workaround is to install my own version of the Makefile in the debian package, but I ask myself if this is really needed or parts of it should also be changed upstream.
I think we should try to move as much as possible upstream in order to reduce the overhead of the package maintainers.
Regards, Marek
Hi,
First thing is that there is a Makefile.kbuild which is included with include $(PWD)/Makefile.kbuild This will not work in the current situation because the PWD is now /usr/src/linux-headers-2.6.29-1-amd64. Is this extra Makefile.kbuild really needed?
the Makefile.kbuild was introduced to support OpenWRT better (OpenWRT uses the kbuild Makefile only and replaces the main Makefile with its own). Could we do the same with debian ?
I do something like this at the moment. I generate the kernel module source .tar.bz2 by with Makefile.kbuild (renamed to Makefile) and add "all" and "clean" target. They are needed to be able to run module-assistent at the moment... maybe I can change this in the future slightly and only use Makefile.kbuild as openwrt does it.
The batmand-gateway cannot be build for linux 2.6 if the current kernel is a 2.4.x. Isn't it possible to make the obj-m and batgat-objs assignment outside the check for the kernel version?
I'm not so sure what you have in mind. Could you explain it further ?
I was thinking a little bit too loud. The problem is that the version of the current running kernel has nothing to do with the version of the kernel which will be the target kernel of the new module. So if somebody (aka build servers) have a 2.4 kernel running and want to build against 2.6... nothing will be build at all. So my first idea was to change the lines
ifeq ($(strip $(findstring $(LINUX26),$(LINUX_VERSION))),$(LINUX26))
obj-m += batgat.o batgat-objs := gateway.o hash.o
else to obj-m += batgat.o batgat-objs := gateway.o hash.o ifneq ($(strip $(findstring $(LINUX26),$(LINUX_VERSION))),$(LINUX26))
but as I don't know what possible side effects are - just forget it. It should be better to check linux/version.h like madwifi does it, but this adds extra overhead by calling CC and again the problem that the batmand-gateway path has to be known when compiling directly over the kernel source/headers as linux- modules-extra-2.6 does it.
The really problem when using (unchanged) Makefile.kbuild in batmand-gateway is that the check for linux-2.6 is not in there - but to patch it for debian is (in my opinion) the cleanest version for everyone.
If no better solution comes to my mind, I would say that nothing should be changed at the moment.
Best regards, Sven
b.a.t.m.a.n@lists.open-mesh.org
-
Marek Lindner -
Sven Eckelmann