1

What are the implications? Is the kernel compiled with static libraries or are they implemented intrinsically?

Also, according to this, kernel code cannot use any floating point operation. Why is that?

Trey
  • 474
  • 2
  • 9
  • 32
  • 3
    Linux can load kernel modules, like many other kernels. https://en.wikipedia.org/wiki/Loadable_kernel_module – Peter Cordes Oct 21 '17 at 09:27
  • It's not strictly true that you can't use FP code in the kernel. Use [`kernel_fpu_begin()` / `kernel_fpu_end()` around your code to avoid corrupting user-space FPU state](https://stackoverflow.com/questions/46677676/why-are-simd-instructions-not-used-in-kernel). https://stackoverflow.com/questions/15883947/why-am-i-able-to-perform-floating-point-operations-inside-a-linux-kernel-module. But if possible, use integer. The kernel could entirely disable the FPU if it wanted: https://stackoverflow.com/questions/13886338/use-of-floating-point-in-the-linux-kernel – Peter Cordes Oct 21 '17 at 09:42
  • Because the shared libraries are not compatible with the environment under which kernel runs (kernel mode vs ld in user land). You always have to produce code, which is valid for your target platform. The target platform "linux kernel mode" is different from "linux user app" target. Why is that: because the user-land environment is created by kernel, so to make kernel prepare same environment for itself, you are getting recursive... (and running "kernel 2" under "kernel 1" is performance ineffective, it's simpler to rather write one-kernel for the bare metal target) – Ped7g Oct 21 '17 at 10:08
  • @Ped7g so is it statically linked? – Trey Oct 21 '17 at 11:18
  • The internal kernel code is statically linked. Mind you, when you compile C source, you end with object files. Whether you archive those into .a library file, or use them one by one during linking doesn't make any difference on principal level, it's just a bit different input file format, but in both cases you are statically linking object files. It sounds like you are particularly interested into some user-land lib? That's off limits, either way, you would need to patch it to be functional in kernel mode (correct API), then you can either link it statically or dynamically as kernel module. – Ped7g Oct 21 '17 at 12:54
  • Is this question in regards to an operating system you are developing from scratch or a specific operating system like Linux? – Michael Petch Oct 21 '17 at 15:53

1 Answers1

5

Why is it not possible to link shared libraries into kernel code?

It is possible. But, they are not the same shared libraries you use in userland.

Since classic System V, kernel can be running as set of loadable modules and is usually being run this way. Virtually all modern systems use this; Linux and FreeBSD are good examples. And, they use the same tools to create such modules as for userland. For example:

shared object of a kernel module:

$ file /lib/modules/4.4.0-97-generic/kernel/drivers/net/vxlan.ko 
'/lib/modules/4.4.0-97-generic/kernel/drivers/net/vxlan.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=561b0b69742c93a595c85be50f6916352c793e5c, not stripped

shared object of a userland library:

$ file /lib64/libm-2.23.so 
/lib64/libm-2.23.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=cb41640d6965fac9bac4010bebac955e95e4d8c1, for GNU/Linux 2.6.32, stripped

the same for FreeBSD:

$ file /boot/kernel/agp.ko 
/boot/kernel/agp.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped

$ file /lib/libm.so.5 
/lib/libm.so.5: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, stripped

in these cases, all are ELF "shared object" (the thing you named "shared library"; the term "shared object" is less obvious but declared in ELF specification) or "relocatable" ("object file"; but the way kernels use it is nearly identical to shared object). You can see subtle differences in file diagnostics, as ELF branding and target specification; they are not principal for this linking. One of the first things that start in a freshly loaded kernel is a runtime linker that is aware of selected object file format and performs initial linking.

But, the thing that is different is that kernel modules are built against different programming interface and, in some cases, against different binary interface. Some library functions can cease; some can be implemented in a rather different way. If you compile and link kernel module without special options intended for kernel, there is major chance it wonʼt run properly (and cause kernel crash). Thatʼs why one should use specific header set and compile options. And, you usually cannot load a userland library into kernel because it depends on symbols that arenʼt present in kernel.

Netch
  • 4,171
  • 1
  • 19
  • 31