Comment by nineteen999
7 years ago
Well it depends on what side of the kernel/userspace boundary you are talking about doesn't it.
While C for userland programs may need to conform to the operating system's libc and system call interface abstractions, on the other side of the syscall boundary is C code (ie. the kernel) that is indeed very "close to the metal".
Except that C's abstract machine is closer to a PDP-11 than an modern i7/ARM are doing.
So unless you are doing PIC programming, that "close to the metal" is very far away.
Running any code in the CPU's most privileged ring, regardless of language, is going to give you access to directly programming the MMU, scheduling processes across multiple CPU's, control over caches to a fairly large extent, and the ability to control every device in the system. A large amount of this is achieved by bit-banging otherwise inaccessible registers in the CPU itself via assembly (ie. in the case of the MMU, GDT and IDT for x86), or via MMIO for modern busses/devices. The language doesn't necessarily "need" to have a complex model of the entire physical machine to be able to achieve all of those things. How much closer to the metal do you want to be?
You really want your programming language to have innate constructs for directly controlling the baggage the x86 CPU (or any other for that matter) brings with it? I don't.
You also want kernel code to be performant (ie. compiled by a decently optimizing compiler, of which there are many for C), allow you to disable garbage collection or be totally free of it so you can explicitly manage separate pools of memory. C ticks all those boxes which is why its still the most dominant and widespread language for OS kernel development nearly half a century since UNIX was first rewritten in C, and will be for years to come, like it or loathe it, and despite there being much more modern contenders (eg. Rust) which don't have the momentum yet.
C doesn't tick any box regarding:
- vector execution units
- out of order execution
- delay slots
- L1 and L2 explicit cache access
- MMU access
- register windows
- gpgpu
All of that is given access by Assembly opcodes, not C specific language features.
And if you going to refer to language extensions to ISO C for writing inline Assembly, or compiler intrinsics, well the first OS written only in high level language with compiler intrinsics was done 10 years before C existed and is still being sold by Unisys.
The only thing that C has going for it are religious embedded devs that won't touch anything else other than C89 (yep not even C99), or FOSS UNIX clones.
And yeah, thanks to those folks, the Linux Kernel Security summit will have plenty of material for future conferences.
10 replies →