programming in Linux kernel and glibc

[sybvn]

Hi all,

I am searching for some document in the Internet, but I have not found it yet.
So I post my question here, hope you guys give me some reference or some information from your knowledge.

I am aware that when we are programming in kernel space, we can definitely call other kernel symbols which are exported to kernel symbol table that we can observe in /proc/ksyms. We can use some glibc functions also, for example the strcmp. But many functions from glibc functions cannot be used in kernel space. They are desinged for user-space program only. Inversely, all glibc functions can be called by user-space program. I would like to know if all above statements are right or not? And where can I find documents that fully point out that thing for all glibc functions?

Thank you very much for your time.

[online]

Hi all,

I am searching for some document in the Internet, but I have not found it yet.
So I post my question here, hope you guys give me some reference or some information from your knowledge.

I am aware that when we are programming in kernel space, we can definitely call other kernel symbols which are exported to kernel symbol table that we can observe in /proc/ksyms. We can use some glibc functions also, for example the strcmp. But many functions from glibc functions cannot be used in kernel space. They are desinged for user-space program only. Inversely, all glibc functions can be called by user-space program. I would like to know if all above statements are right or not? And where can I find documents that fully point out that thing for all glibc functions?

Thank you very much for your time.

You can use some of glibc functions because it was implement in Linux kernel already ( ie strcmp was implement in "kernel/linux/lib/string.c" ).

When you're programming in kernel space, you only can use functions exported by linux kernel.

For more information,read Linux Device Drivers book, Chapter 2

[sybvn]

You can use some of glibc functions because it was implement in Linux kernel already ( ie strcmp was implement in "kernel/linux/lib/string.c" ).

When you're programming in kernel space, you only can use functions exported by linux kernel.

For more information,read Linux Device Drivers book, Chapter 2

Bla, bla, bla, I find so many holes in my understanding the Linux kernel. Yes, cat /proc/ksyms | grep 'strcmp' shows that strcmp is exported by the kernel.

In other words, can I say that actually, codes in kernel space do not reference the glibc at all, they only use the functions exported by the kernel itself; and the strcmp from kernel and the strcmp from glibc are 2 different implementations of the same function logic? The answer is YES is clear, isn't it. Moreover, the use of libc in kernel is impossible because there is no way to do dynamic linking like it does in user space programming, and static link the libc function to kernel code is a bad idea in term of code size. Is it right? I want to correct my understanding in this issue.

[sybvn]

I found a total answer for my question. It is from http://www.kernelnewbies.org/faq/

I suppose any men who do programming in kernel space already know it except me (I really did something in kernel space ). Anyway, I don't want this thread incompleted. So, I copy and patse it here:

System libraries (such as glibc, libreadline, libproplist, whatever) that are typically available to userspace programmers are unavailable to kernel programmers. When a process is being loaded the loader will automatically load any dependent libraries into the address space of the process. None of this mechanism is available to kernel programmers: forget about ISO C libraries, the only things available is what is already implemented (and exported) in the kernel and what you can implement yourself.

Note that it is possible to "convert" libraries to work in the kernel; however, they won't fit well, the process is tedious and error-prone, and there might be significant problems with stack handling (the kernel is limited to a small amount of stack space, while userspace programs don't have this limitation) causing random memory corruption.

Many of the commonly requested functions have already been implemented in the kernel, sometimes in "lightweight" versions that aren't as featureful as their userland counterparts. Be sure to grep the headers for any functions you might be able to use before writing your own version from scratch. Some of the most commonly used ones are in include/linux/string.h.

Whenever you feel you need a library function, you should consider your design, and ask yourself if you could move some or all the code into user-space instead.

[sivagnanam]

hi sybvn,

even iam a newbie to kernel programming. i found the exact questions that are bugging me for a long time.

Iam working in a uClinux based project.

For compiling the uclinux kernel, we r using the uClinux tool chain which consists of gcc,uClibc .. etc. My question is, do we need uClibc to compile the uClinux kernel ..

If i want to compile the uClinux kernal for x86 platform, can i use the native redhat tool chain to compile the kernel (My machine is a X86 clone with redhat 9)

Even i found this thread pretty old, iam expecting some help ..

[sybvn]

hi sivagnanam,

I don't experience with uClinux. And my naive question which started this thread make me worthless to answer your question somehow

Now I stick to the idea that kernel code would not refer to any external libraries but itself. So I would say that you don't need uClibc to compile uClinux kernel. Just guess!

I found on uCLinux site that it isn't ported to x86 (http://www.uclinux.org/ports/). Am I wrong?

[sybvn]

sivagnanam, why don't you just go ahead and try it out.