Exporting new functions from kernel 2.2.14

Exporting new functions from kernel 2.2.14

[Stephen Wille Padnos]

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

RE: Exporting new functions from kernel 2.2.14

[Arthur Naseef]

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

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Stephen Wille
> Padnos
> Sent: Tuesday, June 05, 2001 11:55 AM
> To: Linux Kernel
> Subject: 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
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Exporting new functions from kernel 2.2.14

[Keith Owens]

On Tue, 5 Jun 2001 09:10:56 -0400, 
"Arthur Naseef" <arthur.naseef@ariel.com> wrote:
>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)

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

RE: Exporting new functions from kernel 2.2.14

[Arthur Naseef]

Thanks for being so helpful. Indeed!

> -----Original Message-----
> From: Keith Owens [mailto:kaos@ocs.com.au]
> Sent: Tuesday, June 05, 2001 9:25 AM
> To: Arthur Naseef
> Cc: Linux Kernel
> Subject: Re: Exporting new functions from kernel 2.2.14 
> 
> 
> On Tue, 5 Jun 2001 09:10:56 -0400, 
> "Arthur Naseef" <arthur.naseef@ariel.com> wrote:
> >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)
> 
> Remind me _NEVER_ to answer any of your module problems.  Make up your
> own hash indeed, complete and utter rubbish!

Re: Exporting new functions from kernel 2.2.14

[Stephen Wille Padnos]

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:

...

> you can edit the .ver file yourself (under /usr/src/linux/include/modules/)
> and add entries.  This will eliminate the funny versioning, as in:
> 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
>

Re: Exporting new functions from kernel 2.2.14

[Stephen Wille Padnos]

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

Re: Exporting new functions from kernel 2.2.14

[Keith Owens]

On Tue, 05 Jun 2001 10:32:41 -0700, 
Stephen Wille Padnos <stephenwp@adelphia.net> wrote:
>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 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.

Re: Exporting new functions from kernel 2.2.14

[Keith Owens]

On Tue, 05 Jun 2001 08:54:31 -0700, 
Stephen Wille Padnos <stephenwp@adelphia.net> wrote:
>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

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

Re: Exporting new functions from kernel 2.2.14

[Stephen Wille Padnos]

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)

Keith Owens wrote:

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

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

- Steve

Re: Exporting new functions from kernel 2.2.14

[Keith Owens]

On Tue, 05 Jun 2001 10:10:26 -0700, 
Stephen Wille Padnos <stephenwp@adelphia.net> wrote:
>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?

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.