Re: kernelversion distinction

Re: kernelversion distinction

[sam]

Date: Man, 12 Apr 2004 12:21:44 +0200 skrev Axel Weiss <aweiss@informatik.hu-berlin.de> : 

>Ok, maybe there's some misunderstanding due to copy-n-paste-mistakes
>I made in my former mail.
>
>As I suppose my device drivers will not become part of the official
>kernel, I 
>keep them with my project. My opinion now is to use one Makefile for
>both, 
>2.2-2.4 and 2.6 kernels, and to keep this Makefile simple.

I have never looked at 2.2 so here I cannot help you.
But my original questions remains:
Why you cannot use the same Makefile for 2.4 and 2.6?

A simple Makefile like you outline:
>EXTRA_CFLAGS := -I/usr/include
>obj-m	       += <my_module>.o
><my_module>-objs = <my module object files>

Will work flawlessly with both 2.4 and 2.6.
I know people for a long time have hardcoded the gcc commandline
to build modules for 2.4 - but thats just wrong.
In this way you do not catch differences in gcc options.
For 2.4 we have seen only few of these config related flags to gcc,
in 2.6 we have a lot.

Please next time post the full Makefile.

Btw, a module that is dependent on /usr/include looks wrong...

I have no knowledge of a documented way to distingush between 2.4
and 2.6 in the Makefiles.

>Maybe, I'm not the first one who tries this, or maybe others would
>find it 
>useful - that's the reason why I want to discuss this topic here.
>(If I'm OT, 
>please let me know).
Not OT - please continue.

>
>all:
>	 $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
>
>clean:
>	 rm -f *.o *.ko .*.cmd <my_module>.mod.c

For the new external module support implemented in -mc4 you
do not have to hardcode the clean: target, and no attempts will
be made to update the kernel stuff.
Documentation soon to arrive...

     Sam

Re: kernelversion distinction

[Axel Weiss]

Am Montag, 12. April 2004 15:20 schrieb sam@ravnborg.org:
> Date: Man, 12 Apr 2004 12:21:44 +0200 skrev Axel Weiss <aweiss@informatik.hu-berlin.de> :
> Why you cannot use the same Makefile for 2.4 and 2.6?
On SuSE-9.0 the build simply fails:

rantanplan:/home/axel/freeSP-1.0.3 # make -C drivers/linux/harmonie/
make: Entering directory `/home/axel/freeSP-1.0.3/drivers/linux/harmonie'
make -C driver all
make[1]: Entering directory `/home/axel/freeSP-1.0.3/drivers/linux/harmonie/driver'
make -C /lib/modules/2.4.21-199-axel/build SUBDIRS=/home/axel/freeSP-1.0.3/drivers/linux/harmonie/driver modules
make[2]: Entering directory `/usr/src/linux-2.4.21-199'
make -C  /home/axel/freeSP-1.0.3/drivers/linux/harmonie/driver CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4.21-199/include  -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -fno-unit-at-a-time -pipe -msoft-float -mpreferred-stack-boundary=2 -march=athlon -DMODULE" MAKING_MODULES=1 modules
make[3]: Entering directory `/home/axel/freeSP-1.0.3/drivers/linux/harmonie/driver'
make[3]: *** Keine Regel, um »modules« zu erstellen.  Schluss.
make[3]: Leaving directory `/home/axel/freeSP-1.0.3/drivers/linux/harmonie/driver'
make[2]: *** [_mod_/home/axel/freeSP-1.0.3/drivers/linux/harmonie/driver] Fehler 2
make[2]: Leaving directory `/usr/src/linux-2.4.21-199'
make[1]: *** [all] Fehler 2
make[1]: Leaving directory `/home/axel/freeSP-1.0.3/drivers/linux/harmonie/driver'
make: *** [module] Fehler 2
make: Leaving directory `/home/axel/freeSP-1.0.3/drivers/linux/harmonie'

>
> A simple Makefile like you outline:
> >EXTRA_CFLAGS := -I/usr/include
> >obj-m	       += <my_module>.o
> ><my_module>-objs = <my module object files>
>
> Will work flawlessly with both 2.4 and 2.6.
> I know people for a long time have hardcoded the gcc commandline
> to build modules for 2.4 - but thats just wrong.
> In this way you do not catch differences in gcc options.
> For 2.4 we have seen only few of these config related flags to gcc,
> in 2.6 we have a lot.
>
> Please next time post the full Makefile.
(see eom)
>
> Btw, a module that is dependent on /usr/include looks wrong...
This is because I include the ioctl-definitions, and I put them to /usr/include/dsp, so the kernel module and user-space-lib see the identical file.
Perhaps it would be better to include the local source (in this case ../system_include), I will think over it.

> >clean:
> >	 rm -f *.o *.ko .*.cmd <my_module>.mod.c
>
> For the new external module support implemented in -mc4 you
> do not have to hardcode the clean: target, and no attempts will
> be made to update the kernel stuff.
> Documentation soon to arrive...
Do you think, it would be better to write
clean:
	$(MAKE) -C  $(KDIR) SUBDIRS=$(PWD) clean
?

There are still some inconsistencies, especially when I try to compile a second module. I will investigate this tonight and post cognitions here.

The next problem arises when I have to ditinguish the kernel version within C source. For now I do it like this:
// fw-declaration of /proc-read functions:
#ifdef LINUX_VERSION_CODE
#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 4, 18)
int harmonie_read_proc(char *buf, char **start, off_t offset, int len, int unused);
#else	// 2.4.19 ... < 2.5
int harmonie_read_proc(char *buf, char **start, off_t offset, int cnt, int *eof, void *data);
#endif
#else	// >= 2.5
int harmonie_read_proc(char *buf, char **start, off_t offset, int cnt, int *eof, void *data);
#endif

This looks really ugly, so what is the recommended way to get kernel version information? As the interface for ISRs has changed, too, there is a need for getting kernel version at compile time.

For now, I have a running module for 2.2 - 2.6 :)

Now the complete Makefile:

# ***************************************************************************
#                          makefile  -  description
#
#   This is the harmonie device driver makefile.
#
#                             -------------------
#    begin                : Wed May 29 2002
#    copyright            : (C) 2002 by Axel Weiss
#    email                : aweiss@informatik.hu-berlin.de
# ***************************************************************************/
#
# ***************************************************************************
# *                                                                         *
# *   This program is free software; you can redistribute it and/or modify  *
# *   it under the terms of the GNU General Public License as published by  *
# *   the Free Software Foundation; either version 2 of the License, or     *
# *   (at your option) any later version.                                   *
# *                                                                         *
# ***************************************************************************/


KERNELVERSION := $(shell uname -r)
KERNELBASE    := $(basename $(KERNELVERSION))
KERNELMINOR   := $(suffix $(KERNELBASE))
KERNELMAJOR   := $(basename $(KERNELBASE))

OLD_MODULES := $(strip $(foreach V, .0 .1 .2 .3 .4, $(shell [ "$(V)" = "$(KERNELMINOR)" ] && echo yes)))

ifeq ($(KERNELMAJOR),2)
ifeq ($(OLD_MODULES),yes)	# old style make

DEBUG := yes

CC := gcc

SOURCES := $(wildcard *.c)
HEADERS := $(wildcard *.h)
OBJS := $(SOURCES:%.c=%.o)

CC_FLAGS := -c -Wall -I/lib/modules/`uname -r`/build/include -DMODULE -D__KERNEL__
ifeq ($(DEBUG),yes)
	CC_FLAGS += -DHARMONIE_DEBUG
endif

all: harmonie.o

harmonie.o: $(OBJS)
	$(LD) -r -o $@ $(OBJS)

$(OBJS): %.o:%.c
	$(CC) $(CC_FLAGS) $<

$(OBJS): $(HEADERS) $(SYSTEM_HEADERS_INSTALL)

clean:
	@rm -f $(OBJS) *% *.bak harmonie.o

else #ifeq ($(OLD_MODULES),yes)	new style make

ifneq ($(KERNELRELEASE),)

EXTRA_CFLAGS := -I/usr/include
obj-m         += harmonie.o
harmonie-objs = harmonie_buffer.o harmonie_device.o harmonie_module.o harmonie_procio.o harmonie_io.o

else #ifneq ($(KERNELRELEASE),)

KDIR        := /lib/modules/$(shell uname -r)/build
PWD         := $(shell pwd)

all:
	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

clean:
	rm -f *.o *.ko .*.cmd harmonie.mod.c

endif #ifneq ($(KERNELRELEASE),)
endif #ifeq ($(OLD_MODULES),yes)

else #ifeq ($(KERNELMAJOR),2)	# kernel 1.x ?

all:
	@echo kernel $(KERNELVERSION) not supported

endif #ifeq ($(KERNELMAJOR),2)

2.6.5 - incomplete headers?

[Axel Weiss]

Hi,

I'm going to bring my device drivers[1] from 2.4 to 2.6 and have successfully 
installed kernel-2.6.5 for my athlon-PC.

Compiling (unmodified) 2.4-sources of my modules stops, missing irq_vectors.h.

What do I have to do to successfully include <linux/interrupt.h> from inside a 
kernel module? Or is ther a completely different strategy for ISRs in 2.6? 
(Where is the starting point to read, in this case?)

FYI:

$ uname -r
2.6.5

$ gcc -c -Wall -I/lib/modules/`uname -r`/build/include -DMODULE -D__KERNEL__ 
-DHARMONIE_DEBUG harmonie_io.c
In file included from /lib/modules/2.6.5/build/include/linux/irq.h:20,
                 from /lib/modules/2.6.5/build/include/asm/hardirq.h:6,
                 from /lib/modules/2.6.5/build/include/linux/interrupt.h:11,
                 from harmonie_io.c:44:
/lib/modules/2.6.5/build/include/asm/irq.h:16:25: irq_vectors.h: No such file 
or directory

Regards,
Axel Weiss

[1] device drivers for some dsp-cards, can be found at http://sourceforge.net/
projects/freesp/

kernelversion distinction (was 2.6.5 - incomplete headers?)

[Axel Weiss]

Am Sonntag, 11. April 2004 13:52 schrieb Jan Dittmer:
> Axel Weiss wrote:
> > Hi,
> >
> > I'm going to bring my device drivers[1] from 2.4 to 2.6 and have
> > successfully installed kernel-2.6.5 for my athlon-PC.
> >
> > (Where is the starting point to read, in this case?)
>
> LWN has quite a collection:
>
> http://lwn.net/Articles/driver-porting/
Thanks, very helpful!

Now, I`m trying to be compatible with older kernels (2.2 - 2.4) and want to 
find out what kernel version ist installed, from Makefile. My first solution:

# Makefile
KERNELVERSION := $(shell uname -r)
KERNELBASE    := $(basename $(KERNELVERSION))
KERNELMINOR   := $(suffix $(KERNELBASE))
KERNELMAJOR   := $(basename $(KERNELBASE))

OLD_MODULES := $(strip $(foreach V, .0 .1 .2 .3 .4, $(shell [ "$(V)" = 
"$(KERNELMINOR)" ] && echo yes)))

ifeq ($(KERNELMAJOR),2)
ifeq ($(OLD_MODULES),yes)
#	old style make
endif #ifeq ($(OLD_MODULES),yes)
#	new style make, like pointed out in LWN
else #ifeq ($(KERNELMAJOR),2)
all:
	@echo kernel $(KERNELVERSION) not supported
endif #ifeq ($(KERNELMAJOR),2)

Any improvements? Up to which kernel version should old style make be used?

Regards,
Axel Weiss

Re: kernelversion distinction (was 2.6.5 - incomplete headers?)

[Sam Ravnborg]

> 
> Any improvements? Up to which kernel version should old style make be used?

You cannot use same Makefile for both 2.4 and 2.6?

Using the syntax:
make -C $KERNELSRC SUBDIRS=$PWD modules

should allow you to do that if there is no special requirements.
The Makefile should be an ordinary kbuild Makefile in this case:

obj-m := module.o
module-objs := mod1.o mod2.o
etc..

Another approach would be to keep two Makefiles, one for 2.4, another
for 2.6. Default could be Makefile (for 2.6) and Makefile.24 for older kernels.
This makes much less conditionals.

	Sam

Re: kernelversion distinction

[Axel Weiss]

On Sunday 11 April 2004 22:33, Sam Ravnborg wrote:
> > Any improvements? Up to which kernel version should old style make be
> > used?
>
> You cannot use same Makefile for both 2.4 and 2.6?
>
> Using the syntax:
> make -C $KERNELSRC SUBDIRS=$PWD modules
>
> should allow you to do that if there is no special requirements.
> The Makefile should be an ordinary kbuild Makefile in this case:
>
> obj-m := module.o
> module-objs := mod1.o mod2.o
> etc..
>
> Another approach would be to keep two Makefiles, one for 2.4, another
> for 2.6. Default could be Makefile (for 2.6) and Makefile.24 for older
> kernels. This makes much less conditionals.

Ok, maybe there's some misunderstanding due to copy-n-paste-mistakes I made in 
my former mail.

As I suppose my device drivers will not become part of the official kernel, I 
keep them with my project. My opinion now is to use one Makefile for both, 
2.2-2.4 and 2.6 kernels, and to keep this Makefile simple.

Maybe, I'm not the first one who tries this, or maybe others would find it 
useful - that's the reason why I want to discuss this topic here. (If I'm OT, 
please let me know).

Ok, to become more detailed, I repost my current solution (which seems to work 
for both, 2.4 and 2.6). My question here focusses on the beginning, where I 
distinguish the kernel versions by evaluating 'uname -r' and defining five 
symbols. Is there a more effective way to do it, or is there a danger to 
conflict with the symbol names I chose?

# Makefile
KERNELVERSION := $(shell uname -r)
KERNELBASE    := $(basename $(KERNELVERSION))
KERNELMINOR   := $(suffix $(KERNELBASE))
KERNELMAJOR   := $(basename $(KERNELBASE))

OLD_MODULES := $(strip $(foreach V, .0 .1 .2 .3 .4, $(shell [ "$(V)" = 
"$(KERNELMINOR)" ] && echo yes)))

ifeq ($(KERNELMAJOR),2)
ifeq ($(OLD_MODULES),yes)
#	old style here:
# ...
all:	# ...
clean:
#...
else #ifeq ($(OLD_MODULES),yes)
#	new style here:

ifneq ($(KERNELRELEASE),)
EXTRA_CFLAGS := -I/usr/include
obj-m         += <my_module>.o
<my_module>-objs = <my module object files>

else #ifneq ($(KERNELRELEASE),)

KDIR        := /lib/modules/$(shell uname -r)/build
PWD         := $(shell pwd)

all:
	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

clean:
	rm -f *.o *.ko .*.cmd <my_module>.mod.c

endif #ifneq ($(KERNELRELEASE),)
endif #ifeq ($(OLD_MODULES),yes)
else #ifeq ($(KERNELMAJOR),2)
#	don't want to support 1.x
all:
	@echo kernel $(KERNELVERSION) not supported
endif #ifeq ($(KERNELMAJOR),2)

BTW: I get a warning:
*** Warning: Overriding SUBDIRS on the command line can cause
***          inconsistencies
(which I silently ignore...)

Regards,
Axel Weiss