On Fri, 2008-05-02 at 09:22 +0900, 서청원 wrote: > I got this message during compiling module. > > > > Building modules, stage 2. > > MODPOST > > WARNING: "tasklist_lock" [ /Red/src/Red.ko] undefined! > > make[1]: Leaving directory `/usr/src/linux-headers-2.6.18-4-686' > > > > > > Actually, Red.ko had made but can not load the module due to the > unknown symbol (tasklist_lock). > > > > What’s the problem?? I can see the symbol is exported in the > linux-header-2.6.18-4-686/include/linux/sched.h.
No, it has external linkage within the kernel proper. That's not the same thing as being exported. (But it probably shouldn't be mentioned in this header.) > I couldn’t understand why it is shown “undefined”?? > > > > Also during searching about this problem, I read this - for linux > kernel 2.6.18, the symbol does NOT export any more …. Is this right??? Right. The export was removed by this change: commit c59923a15c12d2b3597af913bf234a0ef264a38b Author: Christoph Hellwig <[EMAIL PROTECTED]> Date: Mon Jul 10 04:45:40 2006 -0700 [PATCH] remove the tasklist_lock export As announced half a year ago this patch will remove the tasklist_lock export. The previous two patches got rid of the remaining modular users. Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> which was merged between 2.6.17 and 2.6.18. > If it is, is there any way to use the symbol ‘tasklist_lock’? > There is my only guess, it is needed the license to use this symbol. Nope. This is the reason it was un-exported: Why: tasklist_lock protects the kernel internal task list. Modules have no business looking at it, and all instances in drivers have been due to use of too-lowlevel APIs. Having this symbol exported prevents moving to more scalable locking schemes for the task list. Ben. -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg
signature.asc
Description: This is a digitally signed message part