[B.A.T.M.A.N.] Out of tree builds of kernel modules

[B.A.T.M.A.N.] Out of tree builds of kernel modules

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [B.A.T.M.A.N.] Out of tree builds of kernel modules

[Marek Lindner]

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

Re: [B.A.T.M.A.N.] Out of tree builds of kernel modules

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]