2004-04-11 11:37:23

by Axel Weiß

[permalink] [raw]
Subject: 2.6.5 - incomplete headers?

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/


2004-04-11 11:52:51

by Jan Dittmer

[permalink] [raw]
Subject: Re: 2.6.5 - incomplete headers?

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

2004-04-11 18:43:24

by Axel Weiß

[permalink] [raw]
Subject: kernelversion distinction (was 2.6.5 - incomplete headers?)

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

2004-04-11 20:26:54

by Sam Ravnborg

[permalink] [raw]
Subject: Re: kernelversion distinction (was 2.6.5 - incomplete headers?)

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

2004-04-12 10:31:42

by Axel Weiß

[permalink] [raw]
Subject: Re: kernelversion distinction

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