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