Exporting Kernel Symbols

Exporting Kernel Symbols

[shesha bhushan]

Hi,
  I have written a new function in linux/fs/read_write.c and I want to make 
the function avaliable to other kernel modules loaded using insmod.
He is what I did:
1. Wrore the func my_func() in linux/fs/read_write.c
2. Used the macro EXPORT_SYMBOL(my_func) inside linux/fs/read_write.c
3. Have a signature of my_func in my_func.h
4. Include my_func.h in linux/fs/read_write.c and my_driver.c
5. Recompiled the kernel
6. Compiler my_driver as loadable module.
7. Brought my new kernel Up.
8 . Insmod my_driver.o
Here I get the error "Unresolved symbol my_func"
Can any one clarify this.

Thanking You
Shesha





_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Re: Exporting Kernel Symbols

[Randy.Dunlap]

On Thu, 13 Feb 2003 20:22:48 +0000
"shesha bhushan" <bhushan_vadulas@hotmail.com> wrote:

| Hi,
|   I have written a new function in linux/fs/read_write.c and I want to make 
| the function avaliable to other kernel modules loaded using insmod.
| He is what I did:
| 1. Wrore the func my_func() in linux/fs/read_write.c
| 2. Used the macro EXPORT_SYMBOL(my_func) inside linux/fs/read_write.c
| 3. Have a signature of my_func in my_func.h
| 4. Include my_func.h in linux/fs/read_write.c and my_driver.c
| 5. Recompiled the kernel
| 6. Compiler my_driver as loadable module.
| 7. Brought my new kernel Up.
| 8 . Insmod my_driver.o
| Here I get the error "Unresolved symbol my_func"
| Can any one clarify this.

For what kernel version?

In 2.4.20, e.g., in linux/fs/Makefile, change the following line:

export-objs :=	filesystems.o open.o dcache.o buffer.o

to include read_write.o

--
~Randy

Re: Exporting Kernel Symbols

[shesha bhushan]

OK I got this working. It was a very silly thing.
linux/fs/read_write.c had not included <linux/module.h> But the kernel 
compilation was not complaining about the useage of EXPORT_SYMBOL without 
including <linux/module.
Now its working fine.

Thanks
-Shesha


>From: "Randy.Dunlap" <rddunlap@osdl.org>
>To: "shesha bhushan" <bhushan_vadulas@hotmail.com>
>CC: linux-kernel@vger.kernel.org
>Subject: Re: Exporting Kernel Symbols
>Date: Thu, 13 Feb 2003 12:26:10 -0800
>
>On Thu, 13 Feb 2003 20:22:48 +0000
>"shesha bhushan" <bhushan_vadulas@hotmail.com> wrote:
>
>| Hi,
>|   I have written a new function in linux/fs/read_write.c and I want to 
>make
>| the function avaliable to other kernel modules loaded using insmod.
>| He is what I did:
>| 1. Wrore the func my_func() in linux/fs/read_write.c
>| 2. Used the macro EXPORT_SYMBOL(my_func) inside linux/fs/read_write.c
>| 3. Have a signature of my_func in my_func.h
>| 4. Include my_func.h in linux/fs/read_write.c and my_driver.c
>| 5. Recompiled the kernel
>| 6. Compiler my_driver as loadable module.
>| 7. Brought my new kernel Up.
>| 8 . Insmod my_driver.o
>| Here I get the error "Unresolved symbol my_func"
>| Can any one clarify this.
>
>For what kernel version?
>
>In 2.4.20, e.g., in linux/fs/Makefile, change the following line:
>
>export-objs := filesystems.o open.o dcache.o buffer.o
>
>to include read_write.o
>
>--
>~Randy
>-
>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/

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: Exporting Kernel Symbols

[shesha bhushan]

Yup I have already appended read_write.o into export-objs list in the 
linux/fs/Makefile.
I am working on Hardhat linux kernel version "2.4.18-rmk7-ds3"

Shesha






>From: "Randy.Dunlap" <rddunlap@osdl.org>
>To: "shesha bhushan" <bhushan_vadulas@hotmail.com>
>CC: linux-kernel@vger.kernel.org
>Subject: Re: Exporting Kernel Symbols
>Date: Thu, 13 Feb 2003 12:26:10 -0800
>
>On Thu, 13 Feb 2003 20:22:48 +0000
>"shesha bhushan" <bhushan_vadulas@hotmail.com> wrote:
>
>| Hi,
>|   I have written a new function in linux/fs/read_write.c and I want to 
>make
>| the function avaliable to other kernel modules loaded using insmod.
>| He is what I did:
>| 1. Wrore the func my_func() in linux/fs/read_write.c
>| 2. Used the macro EXPORT_SYMBOL(my_func) inside linux/fs/read_write.c
>| 3. Have a signature of my_func in my_func.h
>| 4. Include my_func.h in linux/fs/read_write.c and my_driver.c
>| 5. Recompiled the kernel
>| 6. Compiler my_driver as loadable module.
>| 7. Brought my new kernel Up.
>| 8 . Insmod my_driver.o
>| Here I get the error "Unresolved symbol my_func"
>| Can any one clarify this.
>
>For what kernel version?
>
>In 2.4.20, e.g., in linux/fs/Makefile, change the following line:
>
>export-objs := filesystems.o open.o dcache.o buffer.o
>
>to include read_write.o
>
>--
>~Randy
>-
>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/

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: exporting kernel symbols

[Keith Owens]

On Mon, 28 Jan 2002 13:13:38 +0000, 
"kumar M" <kumarm4@hotmail.com> wrote:
>On a freshly installed RedHat 7.1 machine
>with 2.4.2-2 kernel,  a 'make modules'
>throws up  errors such as  :
>----------------------------------------
>/usr/src/linux-2.4/include/linux/module.h:173: nondigits in number and not 
>hexadecimal
>/usr/src/linux-2.4/include/linux/module.h:173: parse error before `62dada05'
>/usr/src/linux-2.4/include/linux/module.h:173: 
>`inter_module_register_R_ver_str' declared as function returning a function
>/usr/src/linux-2.4/include/linux/module.h:173: warning: function declaration 
>isn't a prototype
>.......................................................
>
>So we do a 'make mrproper' and 'make menuconfig' and
>save and exit without any changes to configuration.
>Then we rebuild the kernel.
>make dep & make modules are done smoothly.
>
>Can you let us know why we should be doing make mrproper
>on a system freshly installed  with redhat 7.1(2.4.2-2smp)

RedHat do something strange with module symbols.  I have never
understood what they are trying to do nor why it messes up a normal
kernel compile.  Ask RH what the build procedure is for their
distributed kernels and why a normal build goes wrong.

Re: exporting kernel symbols

[kumar M]

Hi Keith,

Thank you for the info. It was very informative.
My problem is funny.
On a freshly installed RedHat 7.1 machine
with 2.4.2-2 kernel,  a 'make modules'
throws up  errors such as  :
----------------------------------------
/usr/src/linux-2.4/include/linux/module.h:173: nondigits in number and not 
hexadecimal
/usr/src/linux-2.4/include/linux/module.h:173: parse error before `62dada05'
/usr/src/linux-2.4/include/linux/module.h:173: 
`inter_module_register_R_ver_str' declared as function returning a function
/usr/src/linux-2.4/include/linux/module.h:173: warning: function declaration 
isn't a prototype
.......................................................

So we do a 'make mrproper' and 'make menuconfig' and
save and exit without any changes to configuration.
Then we rebuild the kernel.
make dep & make modules are done smoothly.

Can you let us know why we should be doing make mrproper
on a system freshly installed  with redhat 7.1(2.4.2-2smp)

Thanks !

Kumar

>From: Keith Owens <kaos@ocs.com.au>
>To: "kumar M" <kumarm4@hotmail.com>
>CC: linux-kernel@vger.kernel.org
>Subject: Re: exporting kernel symbols
>Date: Mon, 28 Jan 2002 10:37:44 +1100
>
>On Sun, 27 Jan 2002 15:16:10 +0000,
>"kumar M" <kumarm4@hotmail.com> wrote:
> >I am interested in knowing how mangling the name of symbols
> >exported by the kernel to include the checksum of the information related 
>to
> >that symbol is done, whenever MOD VERSIONS
> >is used for building a module. Is there any documentation on the
> >process of the checksum computation, and which portion of the linux
> >sources I need to go through to understand this ?
>
>genksyms.c in the modutils source package[1].  The make dep process
>pre-processes the C sources from each directory feeding the cpp output
>into genksyms.  genksyms calculates a hash for each exported symbol
>based on its type, return values, parameters etc., recursively
>descending parameter types as required.
>
>The resulting hashes are written out as #defines to change foo to
>foo_Rxxxxxxxx.  The defines are read back in when the real compile is
>done, change references to foo into foo_Rxxxxxxxx.  In the kernel the
>original symbols are used but the export list includes the suffix.  In
>modules, external references include the suffix.
>
>In theory if a module refers to a symbol and the hashes for that symbol
>match then the symbol has not changed its ABI and it is safe to load
>the module, even if the kernel and module are from different versions.
>In practice, modversions relies far too much on human processes and is
>prone to false positives.  The hashes can match when the ABI is
>different because of human error[2], especially when people compile
>drivers outside the kernel tree.  Kernel and modutils 2.5 will have a
>completely different method for checking ABI compatibility, if kbuild
>2.5 ever gets in.
>
>[1] http://kernel.org/pub/linux/utils/kernel/modutils/v2.4
>[2] http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2
>




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Re: exporting kernel symbols

[Keith Owens]

On Sun, 27 Jan 2002 15:16:10 +0000, 
"kumar M" <kumarm4@hotmail.com> wrote:
>I am interested in knowing how mangling the name of symbols
>exported by the kernel to include the checksum of the information related to 
>that symbol is done, whenever MOD VERSIONS
>is used for building a module. Is there any documentation on the
>process of the checksum computation, and which portion of the linux
>sources I need to go through to understand this ?

genksyms.c in the modutils source package[1].  The make dep process
pre-processes the C sources from each directory feeding the cpp output
into genksyms.  genksyms calculates a hash for each exported symbol
based on its type, return values, parameters etc., recursively
descending parameter types as required.

The resulting hashes are written out as #defines to change foo to
foo_Rxxxxxxxx.  The defines are read back in when the real compile is
done, change references to foo into foo_Rxxxxxxxx.  In the kernel the
original symbols are used but the export list includes the suffix.  In
modules, external references include the suffix.

In theory if a module refers to a symbol and the hashes for that symbol
match then the symbol has not changed its ABI and it is safe to load
the module, even if the kernel and module are from different versions.
In practice, modversions relies far too much on human processes and is
prone to false positives.  The hashes can match when the ABI is
different because of human error[2], especially when people compile
drivers outside the kernel tree.  Kernel and modutils 2.5 will have a
completely different method for checking ABI compatibility, if kbuild
2.5 ever gets in.

[1] http://kernel.org/pub/linux/utils/kernel/modutils/v2.4
[2] http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2

exporting kernel symbols

[kumar M]

Hi,

I am interested in knowing how mangling the name of symbols
exported by the kernel to include the checksum of the information related to 
that symbol is done, whenever MOD VERSIONS
is used for building a module. Is there any documentation on the
process of the checksum computation, and which portion of the linux
sources I need to go through to understand this ?

TIA.

regards,
Kumar

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.