Exporting new functions from kernel 2.2.14

Hello, all.

I am writing a pseudo-realtime control system, based on kernel 2.2.14. The only RT-like task needs to hang off the timer IRQ. I am using techniques like those in the book "Linux Kernel Internals", by Beck, et al..

The patches in that book won't apply (they are for 2.1.24 or lower), plus I want a somewaht different functionality, which brings me to my
question: How can I get (modversions-enabled) functions exported from arch/i386/kernel/irq.c?

I see in /proc/ksyms that there are some functions exported from there ({enable,disable}_irq, probe_irq_{on,off}, etc.), and they have correct looking versions.

When I add my new finctions to i386ksyms.c:
EXPORT_SYMBOL(grab_timer_interrupt);
EXPORT_SYMBOL(release_timer_interrupt);

I get names like

grab_timer_interrupt_R__ver_grab_timer_interrupt release_timer_interrupt_R__ver_release_timer_interrupt

instead of
local_irq_count_R4d40375f

Additionally, when I make a dummy module (a la Alessandro Rubini's "Hello" module in "Linux Device Drivers"), I get the following warning:
control.c:31: warning: implicit declaration of function `printk_R1b7d4074'
The module seems to work (it printk's "module loaded" on load and "module unloaded" on unload), but I suspect that this is because I am printk()-ing unformatted text strings - only one parameter gets sent.

So, I obviously have missed some basics about:
a) versioning,
b) exporting symbols, and
c) modules.

could soemone please enlighten me, or direct me along the path of enlightenment :)

Thanks
- Steve

Steve:

I still have not figured out the magic that creates the .ver files which would resolve your concern with the symbol versions, but I do know that you can edit the .ver file yourself (under /usr/src/linux/include/modules/) and add entries. This will eliminate the funny versioning, as in:

grab_timer_interrupt_R__ver_grab_timer_interrupt

You can pick a hash value to use. For example, you might add the following:

	#define __ver_grab_timer_interrupt	a1b2c3d4
	#define grab_timer_interrupt	_set_ver(grab_timer_interrupt)

As far as the printk() warning, you need to make sure your module code includes the right header files. In this case, I believe you need to grab <linux/kernel.h> after including <linux/module.h>.

I hope this helps.

-art

Remind me _NEVER_ to answer any of your module problems. Make up your own hash indeed, complete and utter rubbish!

Thanks for being so helpful. Indeed!

Thanks.

Actually, the symbols in question aren't in modules. The kernel is module enabled, but all drivers are being compiled in (this is for an embedded system). My external module (which needs to grab the timer interrupt) is in a separate source tree.

Thanks for the printk info - I guess boneheads like me could use a FAQ that tells which order the miscellaneoud include files need to be in. (I had modules.h after linux.h). I changed the order, butI am waiting for a recompile now, so I don't know if the reordering worked.

Arthur Naseef wrote:

...

Well, my rebuild kernel / reboot / recompile module just finished.

Unfortunately, the printk warning was still there.

I replaced the unconditional #define MODVERSIONS with #include <linux/config.h>
#ifdef CONFIG_MODVERSIONS
#define MODVERSIONS
#include <linux/modversions.h>
#endif

this is at the top of my source file. (before module.h and linux.h)

(as seen somewhere on the web)
and it compiles without warnings now.

Now all I need is some info on module oparameters and using /proc :)

Thanks again.
- Steve

And like many things on the web, it is wrong. Do not put anything in the source code expect #include <linux/module.h> as the first include. In particular do not include modversions.h yourself, it will break in 2.5. You compile a module with these gcc flags

(1) -DMODULE
(2) -DMODVERSIONS -include $(TOPDIR)/include/linux/modversions.h
(3) -DEXPORT_SYMTAB

All modules get flag (1).
All modules get flags (2) but only if .config contains CONFIG_MODVERSIONS, otherwise omit these flags. Only modules that export symbols get flag (3).

That is what the standard kernel Makefiles do and is the only correct way to compile modules.

Keith Owens, kernel build and modutils maintainer.

Read the very last line of every message on linux-kernel.

um. duh.

Thanks. I guess it helps to know the right FM to R. :)

Arthur had pointed out that modules.h should be included, then kernel.h. Is there a place where I can find out more about header file order dependencies? (damn - that sounds like a Microsoft help question)

and to think I used to laugh at people who forgot to do that :)

- Steve

With the existing design for module symbol versions, module.h must appear before other headers, to obtain the mapping of normal symbols to hashed symbols. That restriction will be removed in 2.5, when the broken Makefile design for module versions is replaced.