* RE: Exporting new functions from kernel 2.2.14
2001-06-05 15:54 Exporting new functions from kernel 2.2.14 Stephen Wille Padnos
@ 2001-06-05 13:10 ` Arthur Naseef
2001-06-05 13:24 ` Keith Owens
2001-06-05 17:09 ` Stephen Wille Padnos
2001-06-05 13:23 ` Keith Owens
1 sibling, 2 replies; 10+ messages in thread
From: Arthur Naseef @ 2001-06-05 13:10 UTC (permalink / raw)
To: Stephen Wille Padnos, Linux Kernel
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/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Exporting new functions from kernel 2.2.14
2001-06-05 15:54 Exporting new functions from kernel 2.2.14 Stephen Wille Padnos
2001-06-05 13:10 ` Arthur Naseef
@ 2001-06-05 13:23 ` Keith Owens
2001-06-05 17:10 ` Stephen Wille Padnos
1 sibling, 1 reply; 10+ messages in thread
From: Keith Owens @ 2001-06-05 13:23 UTC (permalink / raw)
To: Stephen Wille Padnos; +Cc: Linux Kernel
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Exporting new functions from kernel 2.2.14
2001-06-05 13:10 ` Arthur Naseef
@ 2001-06-05 13:24 ` Keith Owens
2001-06-05 13:25 ` Arthur Naseef
2001-06-05 17:09 ` Stephen Wille Padnos
1 sibling, 1 reply; 10+ messages in thread
From: Keith Owens @ 2001-06-05 13:24 UTC (permalink / raw)
To: Arthur Naseef; +Cc: Linux Kernel
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!
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Exporting new functions from kernel 2.2.14
2001-06-05 13:24 ` Keith Owens
@ 2001-06-05 13:25 ` Arthur Naseef
0 siblings, 0 replies; 10+ messages in thread
From: Arthur Naseef @ 2001-06-05 13:25 UTC (permalink / raw)
To: Keith Owens; +Cc: Linux Kernel
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!
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Exporting new functions from kernel 2.2.14
2001-06-05 17:10 ` Stephen Wille Padnos
@ 2001-06-05 14:22 ` Keith Owens
0 siblings, 0 replies; 10+ messages in thread
From: Keith Owens @ 2001-06-05 14:22 UTC (permalink / raw)
To: Stephen Wille Padnos; +Cc: Linux Kernel
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Exporting new functions from kernel 2.2.14
2001-06-05 17:32 ` Stephen Wille Padnos
@ 2001-06-05 14:59 ` Keith Owens
0 siblings, 0 replies; 10+ messages in thread
From: Keith Owens @ 2001-06-05 14:59 UTC (permalink / raw)
To: Stephen Wille Padnos; +Cc: Linux Kernel
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Exporting new functions from kernel 2.2.14
@ 2001-06-05 15:54 Stephen Wille Padnos
2001-06-05 13:10 ` Arthur Naseef
2001-06-05 13:23 ` Keith Owens
0 siblings, 2 replies; 10+ messages in thread
From: Stephen Wille Padnos @ 2001-06-05 15:54 UTC (permalink / raw)
To: Linux Kernel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Exporting new functions from kernel 2.2.14
2001-06-05 13:10 ` Arthur Naseef
2001-06-05 13:24 ` Keith Owens
@ 2001-06-05 17:09 ` Stephen Wille Padnos
2001-06-05 17:32 ` Stephen Wille Padnos
1 sibling, 1 reply; 10+ messages in thread
From: Stephen Wille Padnos @ 2001-06-05 17:09 UTC (permalink / raw)
To: Linux Kernel
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
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Exporting new functions from kernel 2.2.14
2001-06-05 13:23 ` Keith Owens
@ 2001-06-05 17:10 ` Stephen Wille Padnos
2001-06-05 14:22 ` Keith Owens
0 siblings, 1 reply; 10+ messages in thread
From: Stephen Wille Padnos @ 2001-06-05 17:10 UTC (permalink / raw)
To: Keith Owens, 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)
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Exporting new functions from kernel 2.2.14
2001-06-05 17:09 ` Stephen Wille Padnos
@ 2001-06-05 17:32 ` Stephen Wille Padnos
2001-06-05 14:59 ` Keith Owens
0 siblings, 1 reply; 10+ messages in thread
From: Stephen Wille Padnos @ 2001-06-05 17:32 UTC (permalink / raw)
To: Linux Kernel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2001-06-05 15:00 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-06-05 15:54 Exporting new functions from kernel 2.2.14 Stephen Wille Padnos
2001-06-05 13:10 ` Arthur Naseef
2001-06-05 13:24 ` Keith Owens
2001-06-05 13:25 ` Arthur Naseef
2001-06-05 17:09 ` Stephen Wille Padnos
2001-06-05 17:32 ` Stephen Wille Padnos
2001-06-05 14:59 ` Keith Owens
2001-06-05 13:23 ` Keith Owens
2001-06-05 17:10 ` Stephen Wille Padnos
2001-06-05 14:22 ` Keith Owens
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox