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 <hch@lst.de>
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 <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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
Attachment:
signature.asc
Description: This is a digitally signed message part