[RFC] External kernel modules

Hello,

the kernel build system (kbuild) allows to compile modules whose sources
live outside the kernel source tree by setting SUBDIRS as follows (from
the module sources's directory):

  $ make -C /lib/modules/$(uname -r)/build modules SUBDIRS=$(pwd)

people use this mechanism to compile kernel modules that are missing in
their kernel sources, or have been updated/fixed in the meantime.

Currently there are a number of deficiencies for building such modules:

  (1) symbol versioning (MODVERSIONS) is not properly supported, and

  (2) only the `modules' make target is supported.

Problem (1) did not exist in the 2.4 kernel series. The current
situation has lead authors of several external modules to implement some
of the kbuild functionality in their own makefiles, which can only lead
to problems later on.

During the kernel compile, a list of all files that export symbols is
created in .tmp_versions/ of the kernel source tree. After everything is
compiled, the module versions of all these object files are resolved
with modpost. When an external module is compiled, it ends up being the
only file in .tmp_versions/, and so symbols in other modules would not
be found.

An additional problem is that resolving symbol versions requires all

Re: [RFC] External kernel modules

On Mon, Feb 02, 2004 at 07:01:21AM +0100, Andreas Gruenbacher wrote:
> I propose the attached patch: It adds symbol version dump/load
> functionality to modpost: When compiling the kernel, the module versions
> are dumped to a file. When compiling external modules, the dumped
> symbols are first loaded. Also, to allow a read-only kernel source tree
> and not interfere with the kernel sources, the .tmp_versions/ directory
> is placed in the external module's directory.
> 
> Furthermore, the patch adds clean/distclean/mrproper make targets with
> reasonable semantics for external modules, and also adds a modules_add
> target that installs the external modules into
> /lib/modules/$(KERNELRELEASE). (The modules_install target could be
> used, but it has different semantics, so I have used a different name
> instead.)

Thanks, I will take a closer look during the week.
Did you consider using the make O=dir support, so .tmp_versions were
created in the output directory?

	Sam

Bug in "select" dependency checking?

Hello,

I think the dependency check in scripts/kconfig/symbol.c has a bug
related to "select", but possibly it's only a misunderstanding what
select is supposed to do. I have the following symbols and dependencies
(simplified):

  config NFS_ACL_SUPPORT
	tristate

  config NFSD
	tristate "..."
	select NFS_ACL_SUPPORT if NFSD_ACL	

  config NFSD_V3
	bool "..."
	depends on NFSD

  config NFSD_ACL
	bool "..."
	depends on NFSD_V3

  config NFS_FS
	tristate "..."
	select NFS_ACL_SUPPORT if NFS_ACL

  config NFS_V3
	bool "..."
	depends on NFS_FS

Re: Bug in "select" dependency checking?

Hi,

On Fri, 6 Feb 2004, Andreas Gruenbacher wrote:

> With this configuration, menuconf gives me this message (among others):
>
>   Warning! Found recursive dependency: NFSD_V3 NFSD_ACL NFSD NFSD_V3

This is indeed a wrong positive, the patch below fixes this, but you if
change your config into e.g.:

config NFSD_ACL
	bool "..."
	depends on NFSD_V3
	select NFS_ACL_SUPPORT if NFSD

you avoid the warning and it does the same.

> In my understanding, the select statement does not cause a dependency of
> NFSD on NFSD_ACL. I can write the same thing without selects as follows:
>
>   config NFS_ACL_SUPPORT
>         tristate
>         default y if (NFSD=y || NFS_FS=y) && (NFSD_ACL || NFS_ACL)
>         default m if (NFSD!=y && NFS_FS!=y) && (NFSD=m || NFS_FS=m) &&
> 		     (NFSD_ACL || NFS_ACL)

Or you could also write this simpler as:

config NFS_ACL_SUPPORT

Re: Bug in "select" dependency checking?

On Fri, 2004-02-06 at 15:00, Roman Zippel wrote:
> Hi,
> 
> On Fri, 6 Feb 2004, Andreas Gruenbacher wrote:
> 
> > With this configuration, menuconf gives me this message (among others):
> >
> >   Warning! Found recursive dependency: NFSD_V3 NFSD_ACL NFSD NFSD_V3
> 
> This is indeed a wrong positive, the patch below fixes this, but you if
> change your config into e.g.:
> 
> config NFSD_ACL
> 	bool "..."
> 	depends on NFSD_V3
> 	select NFS_ACL_SUPPORT if NFSD
>
> you avoid the warning and it does the same.

Does it? I would assume this to limit NFS_ACL_SUPPORT to y or n
depending on the value of NFSD_ACL. If should be y, m or n depending on
the value of NFSD.

> Or you could also write this simpler as:
> 
> config NFS_ACL_SUPPORT
> 	tristate
> 	default (NFSD && NFSD_ACL) || (NFS_FS && NFS_ACL)

That's much more elegant than my "handwired" version. But I prefer

Re: Bug in "select" dependency checking?

Hi,

On Fri, 6 Feb 2004, Andreas Gruenbacher wrote:

> > config NFSD_ACL
> > 	bool "..."
> > 	depends on NFSD_V3
> > 	select NFS_ACL_SUPPORT if NFSD
> >
> > you avoid the warning and it does the same.
>
> Does it? I would assume this to limit NFS_ACL_SUPPORT to y or n
> depending on the value of NFSD_ACL. If should be y, m or n depending on
> the value of NFSD.

That's what the "if NFSD" part does, it's added to the expression and so
modifies how NFS_ACL_SUPPORT is selected. If you enable the debug options
in xconfig you can see the generated expression, which is used to
calculate the final value.
While looking at this, I noticed that a bit too much is added, the NFSD_V3
dependency is also added, but it belongs to NFSD_ACL, otherwise it can
also unintentionally turn the bool into a tristate. I'll have to fix
this...

bye, Roman

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.

Invalid module format

Hi!

I have a makefile which builds my module using the new kbuild system of kernel 2.6. As a result i will get a .o
and a .ko module file which i try to load via insmod. Both of these file return the "invalid module format"
error. The logfile does not give further information on the error. What is the new module format? Is there
any information about it? I've read the kbuild documentation and lots of newsgrep entries but nothing
helped me... Is there a possibility to get more information about my specific error? Has anyone a
solution. I'm beginning to curse the new kernel (((

I had some mail traffic with Andi Kleen who gave me some hints, i should define KBUILD_MODNAME and i  should
enable the "DEBUGP" define
in kernel/module.c and arch/x86_64/kernel/module.c and recompiling to get some information. I mailed
him the output but he couldn't help anymore.

I attached my Makefile and the output from insmod in my logfile.

Thanks for your patience
Carsten

Feb 11 17:36:04 s20c41 kernel: load_module: umod=0000002a95582010, len=132290, uargs=0000000000502010
Feb 11 17:36:04 s20c41 kernel: Core section allocation order:
Feb 11 17:36:04 s20c41 kernel: ^I.text
Feb 11 17:36:04 s20c41 kernel: ^I.fixup
Feb 11 17:36:04 s20c41 kernel: ^I.exit.text
Feb 11 17:36:04 s20c41 kernel: ^I.rodata
Feb 11 17:36:04 s20c41 kernel: ^I__param
Feb 11 17:36:04 s20c41 kernel: ^I__ex_table

[PATCH]2.6.3-rc2 MSI requirements in Kconfig

Having spent a non trivial amount of time trying to pull in the 
code to enable MSI, I would suggest that a clear indication in 
Kconfig that MSI requires CONFIG_PCI_USE_VECTOR would be very helpful.
Also since the MSI code was integrated into 2.6.1 I've updated the 
comment that called for installing the MSI patch.
Martine

--- linux-2.6.3-rc2/arch/i386/Kconfig	2004-02-09 22:00:27.000000000 -0500
+++ linux-2.6.3-rc2_mine/arch/i386/Kconfig	2004-02-12 14:24:37.000000000 -0500
 <at>  <at>  -1056,7 +1056,7  <at>  <at> 
 	default y

 config PCI_USE_VECTOR
-	bool "Vector-based interrupt indexing"
+	bool "Vector-based interrupt indexing (MSI)"
 	depends on X86_LOCAL_APIC && X86_IO_APIC
 	default n
 	help
 <at>  <at>  -1066,11 +1066,11  <at>  <at> 
 	   1) Support MSI implementation.
 	   2) Support future IOxAPIC hotplug

-	   Note that this enables MSI, Message Signaled Interrupt, on all
-	   MSI capable device functions detected if users also install the
-	   MSI patch. Message Signal Interrupt enables an MSI-capable
-	   hardware device to send an inbound Memory Write on its PCI bus
-	   instead of asserting IRQ signal on device IRQ pin.
+	   Note that this allows the device drivers to enable MSI, Message 
+	   Signaled Interrupt, on all MSI capable device functions detected.

Re: [PATCH]2.6.3-rc2 MSI requirements in Kconfig

On Tue, Feb 17, 2004 at 04:36:46PM -0500, Martine Silbermann wrote:
> Having spent a non trivial amount of time trying to pull in the 
> code to enable MSI, I would suggest that a clear indication in 
> Kconfig that MSI requires CONFIG_PCI_USE_VECTOR would be very helpful.
> Also since the MSI code was integrated into 2.6.1 I've updated the 
> comment that called for installing the MSI patch.

You may use this list for reviewing only. If you like to have the patch applied
you should send in on to Andrew Morton or Linus, and I suggest cc: linux-kernel.

	Sam

> Martine

> --- linux-2.6.3-rc2/arch/i386/Kconfig	2004-02-09 22:00:27.000000000 -0500
> +++ linux-2.6.3-rc2_mine/arch/i386/Kconfig	2004-02-12 14:24:37.000000000 -0500
>  <at>  <at>  -1056,7 +1056,7  <at>  <at> 
>  	default y
>  
>  config PCI_USE_VECTOR
> -	bool "Vector-based interrupt indexing"
> +	bool "Vector-based interrupt indexing (MSI)"
>  	depends on X86_LOCAL_APIC && X86_IO_APIC
>  	default n
>  	help
>  <at>  <at>  -1066,11 +1066,11  <at>  <at> 
>  	   1) Support MSI implementation.
>  	   2) Support future IOxAPIC hotplug
>  
> -	   Note that this enables MSI, Message Signaled Interrupt, on all

some problems with if-statements in kconfig

hello list...

when trying to merge some kconfig stuff in respect of CONFIG_PM, i
stumbled upon i problem, i could not resolve yet. this is the context:
there are some (arch-specific) places where CONFIG_PM is defined. when
supplying patches to modify the URL of linux-on-laptops and add the URL
of tuxmobil.org some guy came up with the wish to concentrate PM-stuff
into kernel/power/.
i took a stab at merging the Kconfig stuff, but hit several problems
when trying to eliminate all definitions of "config PM" outside of
kernel/power/Kconfig:

arch/ppp/platforms/4xx/Kconfig
arch/mips/Kconfig
  PM is experimental which is no problem for the dependency, but for the
  prompt "(EXPERIMENTAL)" which does not fit for other archs like x86.

drivers/macintosh/Kconfig
  PM is defined implicitely, there is no prompt to ask the user.

kernel/power/Kconfig
  the help attribute is unaware of architectures, so i changed PM's text
  a little bit. now users of all archs would have to read the full
  text, often not relevant for their specific arch.

attached are three attempts which all fail in their current versions.

Kconfig.if: i prefer this version the most, though it simply does not
work, i do not understand why and perhaps this is due to a bug in
kconfig or badly explained in Documentation/kbuild/kconfig-language.txt