Hi, On Sun, Jan 13, 2013 at 12:09 PM, horseriver <horserivers@gmail.com> wrote:

On Sun, Jan 13, 2013 at 09:27:45PM -0800, Dave Hylands wrote:

...

Hi,

On Sun, Jan 13, 2013 at 11:29 AM, horseriver <horserivers@gmail.com>

wrote:

...

...

hi:

In kernel code . some function is defined by

__attribute__((__section__(".initcall" level ".init")))

...

what does this do ?

It puts the address of the function in a linker section named .initcallX.init where X is replaced by the level.

why ".initcall" and level do not connect together with ## ? As I know , precompiler use ## to connect two strings

That's not quite true. ## is the token pasting operator and is for pasting together pieces of a token to create a larger token. http://gcc.gnu.org/onlinedocs/cpp/Concatenation.html If you have the tokens someVar_ and somethingElse you could token paste them together to make someVar_somethingElse The # operator is a for stringizing,which converts non-strings into strings. http://gcc.gnu.org/onlinedocs/cpp/Stringification.html#Stringification In C and C++ you can "paste" strings together by just putting them one after the other. const char *x = "This is a long string."; is 100% identical to const char *x = "This" " is a long " "string."; http://en.wikipedia.org/wiki/C_syntax#String_literal_concatenation -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com

On Mon, Jan 14, 2013 at 4:50 AM, horseriver <horserivers@gmail.com> wrote:

On Sun, Jan 13, 2013 at 09:27:45PM -0800, Dave Hylands wrote:

...

Hi,

On Sun, Jan 13, 2013 at 11:29 AM, horseriver <horserivers@gmail.com> wrote:

...

hi:

In kernel code . some function is defined by

__attribute__((__section__(".initcall" level ".init")))

...

what does this do ?

It puts the address of the function in a linker section named .initcallX.init where X is replaced by the level.

These functions are called in order to initialize various subsystems and drivers during kernel bootup.

Thanks!

Another question:

__attribute__((regparm(3))) ; what does this do ?

A simple google search should have answered this http://ohse.de/uwe/articles/gcc-attributes.html

Synopsis regparm (NUMBER) Found in versions: 2.7-3.4 Description: On the Intel 386, the `regparm' attribute causes the compiler to pass up to NUMBER integer arguments in registers EAX, EDX, and ECX instead of on the stack. Functions that take a variable number of arguments will continue to be passed all of their arguments on the stack. Beware that on some ELF systems this attribute is unsuitable for global functions in shared libraries with lazy binding (which is the default). Lazy binding will send the first call via resolving code in the loader, which might assume EAX, EDX and ECX can be clobbered, as per the standard calling conventions. Solaris 8 is affected by this. GNU systems with GLIBC 2.1 or higher, and FreeBSD, are believed to be safe since the loaders there save all registers. (Lazy binding can be disabled with the linker or the loader if desired, to avoid the problem.)

...

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

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

-- Thank you Warm Regards Anuz

Hi, On Sun, Jan 13, 2013 at 8:50 PM, horseriver <horserivers@gmail.com> wrote:

On Sun, Jan 13, 2013 at 09:27:45PM -0800, Dave Hylands wrote:

...

Hi,

On Sun, Jan 13, 2013 at 11:29 AM, horseriver <horserivers@gmail.com> wrote:

...

hi:

In kernel code . some function is defined by

__attribute__((__section__(".initcall" level ".init")))

...

what does this do ?

It puts the address of the function in a linker section named .initcallX.init where X is replaced by the level.

These functions are called in order to initialize various subsystems and drivers during kernel bootup.

Thanks!

Another question:

__attribute__((regparm(3))) ; what does this do ?

It causes the compiler to pass the argument (3 in this case) to be passed in registers (like EAX, ECX and EDX) instead of stack. Thanks, Ramesh

...

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

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