2.6.5 - incomplete headers?

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/

Re: 2.6.5 - incomplete headers?

[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/

Jan

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