I recently started hacking on a 75k line C codebase, and I was able to get up and running in a few hours. It’s definitely easier to get into than larger codebases, since you can read 5% of the codebase in a short time. You can e.g. read through entire files to get an idea of what functions are available, and be reasonably certain you’ve seen most of them.
The first function is pretty obvious to anyone that understands x86, it transforms an 80-bit long double into a double (which is probably not a good thing to do). The second bit looks like it is part of an x86 instruction parser for handling the ModR/M encodings, which is a common part of many x86 instruction encodings. The bit twiddling here looks like it is decoding the 2-byte ModR/M operand value.
Context is important for these things. I would prefer code like this to contain some comments and references to the bit of the spec that they’re implementing, but for someone with a passing familiarity with x86 it’s not that hard to read. I would expect that most people that might want to usefully contribute would know enough about x86 to be able to follow that code.
In a slightly higher-level language (C++, Rust, and so on), the bit twiddling would be replaced by helpers to extract specific bit ranges (and the methods would be attached to the class that they’re operating over), but the code probably wouldn’t be very different overall.
That’s a slightly misleading comparison because a lot of that is driver emulators. Of the remainder, this also includes several different architectures. The x86 portion is quite small and TCG is pretty approachable (in spite of starting life as an obfuscated C competition entry).
I would really like it better if it’d implement POSIX- instead of Linux-Syscalls, but I suspect the ship of “POSIX-compatible as a baseline” has sailed a few years ago…
POSIX doesn’t specify system calls, it specifies libc interfaces. An implementation needs to decide what is implemented at each layer. As a baseline, POSIX is also annoying because they never standardised a good event source API. Solaris has /dev/poll, FreeBSD introduced kqueue which XNU inherited, and then Linux decided to implement something worse than either with epoll and then something better with io_uring.
If you want to provide a POSIX (rather than Linux) x86 layer, then you need to provide a libc and to at that point you’re requiring people to build their binaries specifically against your platform, rather than build Linux binaries. If you’re doing that, why target x86 and not some portable ISA that’s designed to be easy to emulate?
I kinda agree, but tbf, one of the cool things about this is being able to run an entire distro with a working package manager. Would that be possible without any Linux-specific syscalls? Is there some pure-POSIX distro that can run on all kernels?
While I get that this is impressive for what they do, 63k lines of C is in no way “approachable”
I recently started hacking on a 75k line C codebase, and I was able to get up and running in a few hours. It’s definitely easier to get into than larger codebases, since you can read 5% of the codebase in a short time. You can e.g. read through entire files to get an idea of what functions are available, and be reasonably certain you’ve seen most of them.
…especially when that code looks like
or
The first function is pretty obvious to anyone that understands x86, it transforms an 80-bit long double into a double (which is probably not a good thing to do). The second bit looks like it is part of an x86 instruction parser for handling the ModR/M encodings, which is a common part of many x86 instruction encodings. The bit twiddling here looks like it is decoding the 2-byte ModR/M operand value.
Context is important for these things. I would prefer code like this to contain some comments and references to the bit of the spec that they’re implementing, but for someone with a passing familiarity with x86 it’s not that hard to read. I would expect that most people that might want to usefully contribute would know enough about x86 to be able to follow that code.
In a slightly higher-level language (C++, Rust, and so on), the bit twiddling would be replaced by helpers to extract specific bit ranges (and the methods would be attached to the class that they’re operating over), but the code probably wouldn’t be very different overall.
some days I think “maybe I should go back to my college days and write some C,” but comments like this keep me on the holy path
This is the kind of code that needs copious comments.
It’s easy to cherry pick bad examples. Here’s a good one:
Intel’s ALU instructions are the most important thing. You won’t find a more succinct elegant implementation of them.
It’s probably relative. How many lines in Qemu?
Qemu has 1,730,794 lines of code.
That’s a slightly misleading comparison because a lot of that is driver emulators. Of the remainder, this also includes several different architectures. The x86 portion is quite small and TCG is pretty approachable (in spite of starting life as an obfuscated C competition entry).
I would really like it better if it’d implement POSIX- instead of Linux-Syscalls, but I suspect the ship of “POSIX-compatible as a baseline” has sailed a few years ago…
POSIX doesn’t specify system calls, it specifies libc interfaces. An implementation needs to decide what is implemented at each layer. As a baseline, POSIX is also annoying because they never standardised a good event source API. Solaris has /dev/poll, FreeBSD introduced kqueue which XNU inherited, and then Linux decided to implement something worse than either with epoll and then something better with io_uring.
If you want to provide a POSIX (rather than Linux) x86 layer, then you need to provide a libc and to at that point you’re requiring people to build their binaries specifically against your platform, rather than build Linux binaries. If you’re doing that, why target x86 and not some portable ISA that’s designed to be easy to emulate?
I kinda agree, but tbf, one of the cool things about this is being able to run an entire distro with a working package manager. Would that be possible without any Linux-specific syscalls? Is there some pure-POSIX distro that can run on all kernels?