How to use a "no-require-kernel" part of libc in kernel

[dlarudgus20]

As we know, we can't use libc to do osdev because it requires features of kernel. However, there's no-required and so nice features in libc, such "snprintf" "strtod" and..

Is there no way to use them? Should I really implement or extract from libc them for myself?

[sortie]

There is no reason you can't use those, feel free to use them in the kernel. You do need an implementation of them, however. The user-space libc is unfit for inclusion in the kernel as it may follow a slightly different ABI (such as using the red zone on x86-64 or floating point stuff) that is incompatible with the kernel, or depends on hosted features from a kernel such as system calls. That is, you shouldn't use an existing libc binary, not even the libcs that come with Linux. What you want to do instead is have a special kernel libc, some systems call that a libkern, a libk, or whatever. The important part is that only the actually freestanding stuff (like snprintf and strlen) is in the library and it is built exactly like the kernel is.

I wrote my own custom libc for my operating system, so I included a dual mode in it: It can be built normally as a user-space libc, or as the special libk where only freestanding (not transitively depending on system calls) functions are included. This means that the kernel is able to use the standard headers like <string.h> and call most (but not all) functions in them. This is a lot of work, though, writing all those freestanding libc parts (though it is good experience). You can likely adapt existing implementations of all the needed functions and include them in your kernel and write some headers for them. Mind that this may conflict with the headers of your actual libc in user-space, when you get that far, though either you can turn that into a kernel libc, or do various tricks.

[hometue]

Just curious, do you ever update the library?

[sortie]

Just curious, do you ever update the library?

My libc and libk are the same library, that is, they are built from the same source code. The libc build step also installs the libk, so that the kernel can link against it when it is compiled later. The different is just that particular source files are excluded in the kernel build and a few predefined macros are set differently.

[thomasloven]

I do the same thing with newlib.

A short description of my method can be found here http://thomasloven.com/blog/2013/08/Catching-Up/

[bluemoon]

One of the simplest way is to build a separated version of libc (or libk in above mentioned replies), using newlib and write the few "syscall" handlers, which is not supposed to be called, with panic (which in turn may be a debug syscall). So whenever you called a system dependent libc function you can easily catch them.

[sortie]

Beware that the libc must be built with similar compile options as the kernel if it must be used as a kernel library. This is less of a concern on i386, but can become potentially very dangerous on x86_64 with the red zone and -m 3dnow -msee -msse2 on by default if the kernel assumes these options are off. Therefore two separate libc binaries are needed (for one user-space and one for the kernel), it's an error to use the same one both places. If you adapt newlib for kernel use, be sure to ensure it is compiled in the same manners as the kernel.

(This is not a reply to anyone else, just a friendly heads up for those that find the thread and follow the advise)

[dlarudgus20]

Thank all of you!