System libraries (such as libc, libm, etc.) that are available to user-space 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. Libraries can be linked statically to kernel modules. This is in fact useful for math functions, but generally not a good thing to do. To statically include libm something like the Makefile entry below should be used.
my_mod.o: my_mod.c
$(CC) ${INCLUDE} ${CFLAGS} -c -o tmp.o my_mod.c
$(LD) -r -static tmp.o -o my_mod.o -L/usr/lib -lm
rm -f tmp.o
Naturally this can have side effects, as library functions are not designed to run in kernel context. Therefore it has to be verified what the functions in the library included are doing.
The standard libc code can be used instead as basis for kernel re-implementation, as there might be significant problems with stack handling (the kernel is limited to a small amount of stack space, while user-space 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 user-land counterparts. Therefore, usage should not be based on the man-pages of the corresponding libc functions. The headers for any functions to be used can be "`grepped"' before writing kernel versions from scratch. If such functions are written, they should be contributed back to the Linux community. Some of the most commonly used ones are in include/linux/string.h.
Whenever a library function is needed, it should be considered in the design phase whether all the code can be moved into user-space instead, or to limit the functions to those available in the kernel. Generally modifying and adding to the kernel should be limited to the really necessary.