From: Mitch D. <mj...@al...> - 2000-09-23 07:25:59
|
>Mitch Davis wrote: > >> I would like to be able to use kernel modules with >> the latest 2.4.x kernel. Does anyone know how >> to do this? > >Hi Mitch, > >I wrote a insmod.c patch for the BusyBox project which enables their >insmod to load SH modules. It seems to work OK with my module code, but >it complains about some symbols not being availible if I try to load >modules built from the kernel sources (af_packet, ramfs, dummy, >etc)--usually it's memset, memcpy, etc but sometimes flush_dcache_page >is also unresolved. I'm not sure if this is a problem with my patch or >with the kernel code, but if you want to give it a shot: Thanks Bryan, I really appreciate that. Actually, David McKay also sent me his version, which was great. I compiled his version (based on modutils 2.3.7) and had the same problem. I fixed it quite simply by adding these lines to arch/sh/kernel/sh_ksyms.c: #include <asm/pgtable.h> EXPORT_SYMBOL(flush_dcache_page); EXPORT_SYMBOL(memset); EXPORT_SYMBOL(memcpy); (I don't know if this is the way to really fix it - simply does not imply correctly!) I too compiled busybox this evening. Wow, it's truly impressive! >CVS kernel code. Did the module interface change between 2.2 and 2.4, >causing modutils-2.1.121 to have trouble loading 2.4 modules? (I based >my patch on an SH patch for 2.1.121). Yes I'm fairly sure it did. Anyway, my thanks again to you and David. Regards, Mitch. http://www.alphalink.com.au/ |
From: Bryan R. <br...@ix...> - 2000-09-26 22:03:32
|
Mitch Davis wrote: [regarding unresolved symbols when loading SH modules] > I compiled his version (based on modutils 2.3.7) and had > the same problem. I fixed it quite simply by adding > these lines to arch/sh/kernel/sh_ksyms.c: > > #include <asm/pgtable.h> > > EXPORT_SYMBOL(flush_dcache_page); > > EXPORT_SYMBOL(memset); > EXPORT_SYMBOL(memcpy); > > (I don't know if this is the way to really fix it - simply > does not imply correctly!) A look in arch/arm/kernel/armksyms.c suggests that it is sh_ksyms.c responsibility to export mem routines--whether or not we have fast assembly code for them in arch/sh/lib/*.S Here's a proposed patch against the latest LinuxSH CVS kernel's sh_ksyms.c: ----- --- sh_ksyms-orig.c Tue Sep 26 13:46:27 2000 +++ sh_ksyms.c Tue Sep 26 14:35:22 2000 @@ -17,6 +17,7 @@ #include <asm/hardirq.h> #include <asm/delay.h> #include <asm/irq.h> +#include <asm/pgtable.h> extern void dump_thread(struct pt_regs *, struct user *); extern int dump_fpu(elf_fpregset_t *); @@ -36,6 +37,21 @@ EXPORT_SYMBOL(strpbrk); EXPORT_SYMBOL(strstr); EXPORT_SYMBOL(strlen); + +/* mem exports */ +EXPORT_SYMBOL(memcpy); +EXPORT_SYMBOL(memset); +EXPORT_SYMBOL(memmove); + +/* these are not provided by arch/sh/lib/*.S but are + potentially needed by modules (af_packet.o/unix.o + use memcmp, for instance) */ +EXPORT_SYMBOL(memcmp); +EXPORT_SYMBOL(memscan); + +/* needed by some modules */ +EXPORT_SYMBOL(flush_dcache_page); #ifdef CONFIG_VT ----- I think this patch should go into the main CVS tree ASAP since without these symbols it is impossible to load most kernel source modules! (almost all of them use some mem* routines) With my patch, dummy.o ramfs.o unix.o and af_packet.o all load (and appear to function) correctly: /lib/modules # uname -a Linux (none) 2.4.0-test9 #6 Tue Sep 26 14:48:06 PDT 2000 sh4 unknown /lib/modules # lsmod Module Size Used by ixdma 1676 0 (unused) ramfs 2548 0 (unused) dummy 1164 0 (unused) af_packet 9596 0 (unused) unix 16260 0 (unused) Comments Niibe-san? Regards, Bryan -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
From: NIIBE Y. <gn...@ch...> - 2000-09-27 00:42:10
|
Bryan Rittmeyer wrote: > Here's a proposed patch against the latest LinuxSH CVS kernel's > sh_ksyms.c: Thanks a lot. > +/* these are not provided by arch/sh/lib/*.S but are > + potentially needed by modules (af_packet.o/unix.o > + use memcmp, for instance) */ > +EXPORT_SYMBOL(memcmp); > +EXPORT_SYMBOL(memscan); > + > +/* needed by some modules */ > +EXPORT_SYMBOL(flush_dcache_page); I think that "memscan" is bogus here, as we define memscan==>memchr in asm-sh/string.h, isn't it? Except that, all is OK. -- |
From: Bryan R. <br...@ix...> - 2000-09-29 21:42:42
|
NIIBE Yutaka wrote: > I think that "memscan" is bogus here, as we define memscan==>memchr in > asm-sh/string.h, isn't it? Except that, all is OK. Yes, you're correct. Sorry about that mistake. Here's the new patch: ------ --- sh_ksyms-orig.c Tue Sep 26 13:46:27 2000 +++ sh_ksyms.c Tue Sep 26 14:35:22 2000 @@ -17,6 +17,7 @@ #include <asm/hardirq.h> #include <asm/delay.h> #include <asm/irq.h> +#include <asm/pgtable.h> extern void dump_thread(struct pt_regs *, struct user *); extern int dump_fpu(elf_fpregset_t *); @@ -36,6 +37,21 @@ EXPORT_SYMBOL(strpbrk); EXPORT_SYMBOL(strstr); EXPORT_SYMBOL(strlen); + +/* mem exports */ +EXPORT_SYMBOL(memcpy); +EXPORT_SYMBOL(memset); +EXPORT_SYMBOL(memmove); + +/* this is not provided by arch/sh/lib/*.S but is + potentially needed by modules (af_packet.o/unix.o + use memcmp, for instance) */ +EXPORT_SYMBOL(memcmp); + +/* needed by some modules */ +EXPORT_SYMBOL(flush_dcache_page); #ifdef CONFIG_VT ----- I think this one should be good to go into the CVS archive. Should I submit it through the SourceSafe patch manager or can you take care of it, Niibe-san? Regards, Bryan -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
From: NIIBE Y. <gn...@ch...> - 2000-09-30 03:39:27
|
Bryan Rittmeyer wrote: > I think this one should be good to go into the CVS archive. Should I > submit it through the SourceSafe patch manager or can you take care of > it, Niibe-san? Thanks. Applied and committed. -- |