Hello Dave, I tried to explain this feature (no doubt you have explain it perfectly) but he is looking for _how_ kernel module gets loaded and somehow (I wonder how!) dubs the entire process as "incremental link" ! On 23 May 2012 21:47, Dave Hylands <dhylands@gmail.com> wrote:

Hi Somanath,

On Tue, May 22, 2012 at 2:56 AM, somanath sahoo <bapi_mvit2004@yahoo.com> wrote:

...

Hi,

As newbie in linux kernel, I would like to understand the concept of "incremental linking " w.r.t to linux kernel module.

Incremental linking is basically just taking some objects files, linking them together to produce a larger object file. The object file still has undefined references. It will also coalesce sections of the same name. The kernel likes to use sections for storing pointers to initcall functions and other things like that.

Some people might also call this partial linking. The kernel uses this technique for the main portion of the kernel as well. If you look through your build directory, you will find a whole bunch of built-in.o files. Each one of these is a partially linked object file containing all of the object files from the current directory and built-in.o files from directories below.

With kernel modules, there are some special automatically generated C files which also get linked in (IIRC that have a name like foo.mod.c)

A kernel module is conceptually identical to a shared library (which is also partially linked and may contain unresolved references).

You can do incremental linking  by doing:

echo "int foo1(void) { return 1; }" > foo1.c echo "int foo2(void) { return 2; }" > foo2.c gcc -c foo1.c gcc -c foo2.c ld -r -o foo.o foo1.o foo2.o

You'll now have foo.o which has both foo1.o and foo2.o partially linked together, which you can see by using:

nm foo.o

-- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com

_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

On Wed, May 23, 2012 at 10:51 AM, Sarbojit Ganguly <unixman.linuxboy@gmail.com> wrote:

Hello Dave,

I tried to explain this feature (no doubt you have explain it perfectly) but he is looking for _how_ kernel module gets loaded and somehow (I wonder how!) dubs the entire process as "incremental link" !

The easiest way to see the whole process happening is to turn on debug, then modprobe a module. youll see lots of details. If you build 3.5-rc0 (ie rc1 is not done yet), and turn on CONFIG_DYNAMIC_DEBUG, you can enable the pr_debugs selectively, and narrow down to the info that you want. heres some of the info youll see: jimc@jimc-desktop:~/projects/lx/linux-2.6$ grep pr_debug kernel/module.c pr_debug("Failed to find symbol %s\n", name); pr_debug("%s uses %s!\n", a->name, b->name); pr_debug("%s does not use %s!\n", a->name, b->name); pr_debug("Allocating new usage for %s.\n", a->name); pr_debug("%s unusing %s\n", mod->name, i->name); pr_debug("Looking at refcount...\n"); pr_debug("%s already dying\n", mod->name); pr_debug("Found checksum %lX vs module %lX\n", pr_debug("Common symbol: %s\n", name); pr_debug("Absolute symbol: 0x%08lx\n", pr_debug("Core section allocation order:\n"); pr_debug("\t%s\n", sname); pr_debug("Init section allocation order:\n"); pr_debug("\t%s\n", sname); pr_debug("\t%s\n", info->secstrings + symsect->sh_name); pr_debug("\t%s\n", info->secstrings + strsect->sh_name); pr_debug("final section addresses:\n"); pr_debug("\t0x%lx %s\n", pr_debug("load_module: umod=%p, len=%lu, uargs=%p\n", I dont recall if it gets into symbol-by-symbol linking, but it might. Read Doc/dynamic_debug_howto for more usage info. Daves simple example would be valuable to look at, esp with readelf and objdump.

On 23 May 2012 21:47, Dave Hylands <dhylands@gmail.com> wrote:

...

Hi Somanath,

On Tue, May 22, 2012 at 2:56 AM, somanath sahoo <bapi_mvit2004@yahoo.com> wrote:

...

Hi,

As newbie in linux kernel, I would like to understand the concept of "incremental linking " w.r.t to linux kernel module.

Incremental linking is basically just taking some objects files, linking them together to produce a larger object file. The object file still has undefined references. It will also coalesce sections of the same name. The kernel likes to use sections for storing pointers to initcall functions and other things like that.

Some people might also call this partial linking. The kernel uses this technique for the main portion of the kernel as well. If you look through your build directory, you will find a whole bunch of built-in.o files. Each one of these is a partially linked object file containing all of the object files from the current directory and built-in.o files from directories below.

With kernel modules, there are some special automatically generated C files which also get linked in (IIRC that have a name like foo.mod.c)

A kernel module is conceptually identical to a shared library (which is also partially linked and may contain unresolved references).

You can do incremental linking  by doing:

echo "int foo1(void) { return 1; }" > foo1.c echo "int foo2(void) { return 2; }" > foo2.c gcc -c foo1.c gcc -c foo2.c ld -r -o foo.o foo1.o foo2.o

You'll now have foo.o which has both foo1.o and foo2.o partially linked together, which you can see by using:

nm foo.o

-- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com

_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies