question regarding global symbols & namespace.pl script

Hi,

I have a very basic question regarding global symbols.

Does the Linux kernel build system provide each kernel module with its own namespace for global symbols?

For instance, Keith Owens points out in an old email that "there are guaranteed to
be conflicts on static and global but unexported symbols" (within one module:
http://www.ussg.iu.edu/hypermail/linux/kernel/9909.0/0433.html), which seems to imply that only exported symbols of a module are entered into the global namespace and that programmers can use global symbols to communicate across .o files with a module freely.

However, if a given subsystem is not built as a module, but rather using the 'y'
option builtin to the kernel, how does the linker know how to respect these per-module
namespaces?

Or is it possible that - depending on the configuration - a global symbol might cause a doubly-defined error in one (non-module) build configuration, but not when
built as a module?

I tried the namespace.pl script Keith wrote, however, I'm getting numerous messages such as this one when running namespace.pl in the Linux kernel top-level dir:

No source file found for arch/i386/kernel/process.o
...

despite the fact that arch/i386/kernel/process.c exists. Could this be due to tool incompatibilities? For instance, objdump -s -j .comment shows:
arch/i386/kernel/process.o: file format elf32-i386

Contents of section .comment:
0000 00474343 3a202847 4e552920 332e3100 .GCC: (GNU) 3.1.

whereas namespace.pl seems to expect:
/GCC\:.*GCC\:/m
(?)
Note this is on a 2.6.8.1 kernel build.

I would be helpful for any answers, particularly to my first question.

Thanks!

- Godmar

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

hello,

<snip>

please ask on kernelnewbies.
aka -> http://www.kernelnewbies.org/

this list is about the kernel janitor project.
aka - http://janitor.kernelnewbies.org/

happy hacking
maks

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

That sounds right to me.

First one I see is this:

dev is multiply defined in :-
drivers/isdn/i4l/isdn_common.o
sound/oss/wavfront.o

and both of these have a variable 'dev' that is not static and not exported. It looks like they show up in the System.map file as having a numbered suffix added to them, like dev.4 and dev.6 .

There was a recent bug where 2 drivers used a variable name of 'debug' for a debug flag (duh). One of them had to be changed. Both of them should have been changed IMO.

Why weren't these debug.1 and debug.2 ? I dunno. Maybe because they were module parameters (?).

Anyway, all of this is an experiment that you can do at home. :)

I didn't see that one, or any that were incorrect AFAIK (of the "No source file found" message). For me these all came from objects that were named differently than their source files by the Makefiles.

Mine also says that (like yours), I don't get it....

Keith is definitely the best person to ask about this.

rddunlap@gargoyle:/mnt/box/linux-2611-rc2-bk5/arch/i386/kernel> objdump -s -j .comment process.o

process.o: file format elf32-i386

Contents of section .comment:
0000 00474343 3a202847 4e552920 332e332e .GCC: (GNU) 3.3.
0010 33202853 75534520 4c696e75 782900 3 (SuSE Linux).

~Randy


_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

FWIW, I followed the advice and asked Matt Domsch on kernelnewbies and he told me that the module namespaces are *not* intentionally separated.

Rather, the fact that two modules sometimes define global symbols by the same name is only an artifact of people testing their kernels in module-only configurations only where it doesn't show up because insmod hides unexported global symbols.

Apparently, an option "make allyesconfig" exists that will force all modules to be compiled with 'y' so that these clashes become apparent. Not allowing global name clashes is now the official policy of the kernel maintainers. I assume that's why namespace.pl was added in 2.6.9.

- Godmar

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

Regarding the namespace.pl issue, it seems that this script is not intended to be run from the command line without setting the srctree and objtree environment variables first.

The reason is that File::Find apparently chdir's into the directory where the file is located, so the test on line 176: if (! -e "$source.c" fails because $source is set to arch/i386/process/kernel.c, but the current directory is already ./arch/i386/kernel. I saw in an strace that stat64("process.o") succeeded right before stat64("arch/i386/process/kernel.c") failed. It works fine with setting objtree and srctree beforehand.

The problem with GNU vs GCC might be an unrelated issue, but since the .c file existed, it should not have executed the code that failed.

Thanks!

- Godmar

ps: I apologize for the linebreaks in this email - does anybody know how to use gmail with a monospace font in a htmlarea?

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors