Skip to contentSkip to conversation

modversion.h improvement suggestion

DISCUSSION Sebastian Huber 4 participants 5 messages May 5, 2002 – May 7, 2002

lore
Share & tools
lore
#0 lore raw

Hello,
I tried to compile a device driver module and got the error that 'modversion.h' cannot be found. My first questions were:
Are the include paths ok?
Do the maintainer now what he or she is doing?
Uses this driver code obsolete kernel stuff?
Has SuSE forgotten something to install?
Then I started a google search for 'modversion.h' and noticed that this was a common problem. And after a while I found the solution -> modversion.h is an automatically generated file.

So what about a default modversion.h file:
/* This is an automatically generated file. Do not edit it. */ #error You have not generated the module versions. You have to ...

This hint may save some time for those who are not so fit in kernel issues.

Ciao
Sebastian

PS:
I'm not a member of this mailing list, so please cc me mails related to that subject.

#1 lore raw
Quoted 3 lines · Sebastian Huber

So what about a default modversion.h file:
/* This is an automatically generated file. Do not edit it. */ #error You have not generated the module versions. You have to ...

No.

It is a big mistake to ship a file and overwrite it under the same name. It messes up source repositories.

Any code that has an explicit #include <linux/modversions.h> is broken. The kernel build automatically includes modversions.h when required.

The build instructions for third party modules should say something like

If your kernel was built with CONFIG_MODVERSIONS=y then add these flags to the build for this module

-DMODVERSIONS -include kernel_source_tree/linux/modversions.h

In any case, modversions.h will disappear in kbuild 2.5.

#2 lore raw
In reply to Sebastian Huber
Quoted 2 lines

I tried to compile a device driver module and got the error that 'modversion.h' cannot be found. My first questions were:

A device driver should not be directly including modversions.h. Its included automatically by the kernel build line only in the case where CONFIG_MODVERSIONS is set.

If the module is being built seperate to the tree then it should probably borrow the Make rules the kernel uses

#3 lore raw
In reply to Sebastian Huber
Quoted 7 lines

The build instructions for third party modules should say something like

If your kernel was built with CONFIG_MODVERSIONS=y then add these flags to the build for this module

-DMODVERSIONS -include kernel_source_tree/linux/modversions.h

or even better, pick up the _complete_ compilation rule from the kernel Makefile, since this is (unfortunately) by now the only way to get all compiler options right.

I do it this way (in a configure.in for an external module):
KSRC is the kernel source location.

  cp $KSRC/Makefile conftest.make
  echo -e "conftest.CC:" >>conftest.make
  echo -e "\t@echo \$(CC)" >>conftest.make
  echo -e "conftest.CFLAGS:" >>conftest.make
  echo -e "\t@echo \$(CFLAGS) \$(MODFLAGS)" >>conftest.make
  here=`pwd`
  NKCC=`cd $KSRC; $MAKE -s -f $here/conftest.make conftest.CC`
  NKCFLAGS=`cd $KSRC; $MAKE -s -f $here/conftest.make conftest.CFLAGS`

i.e. copy the main Makefile, add a few rules to just echo the flags, and then invoke it in the original place (since it depends on that). We should really have a more elegant way to extract this info from the main Makefile.

Quoted 1 line

In any case, modversions.h will disappear in kbuild 2.5.

which leaves hope this issue will be addressed...

Olaf

#4 lore raw
Quoted 9 lines · Olaf Titz

i.e. copy the main Makefile, add a few rules to just echo the flags, and then invoke it in the original place (since it depends on that). We should really have a more elegant way to extract this info from the main Makefile.

kaos wrote

Quoted 1 line

In any case, modversions.h will disappear in kbuild 2.5.

which leaves hope this issue will be addressed...

kbuild 2.5 has full and officially maintained support for compiling code that is not yet in the main kernel tree. No more hacks to get external drivers, filesystems etc. to build.