vmlemon
commented
5 years ago Ideally, we'd upgrade the toolchain to something shiny, and modern, and fix everything, in a big bang, but given the age of the code, it might be best if we gradually work through generations of toolchain, to see how things break - although that would delay implementing more interesting stuff, and take a very long time.
We can still take that approach, but one way to extract ourselves from having to maintain ancient Docker images, and VMs would be to implement the Linux ABI itself (see issue #7), to a point where we can just unpack DEBs/RPMs, and run the toolchain on Orion, without having to rebuild it, and implement perfect source/feature compatibility with everything, immediately.
Since the goal is to eventually become self-hosting, and make a usable system, this could also help with fleshing out a design for things like memory management, and file system APIs, by giving a baseline feature set to work towards.
In predecessor projects (e.g. Enryo, and i9), we used older versions of the GCC toolchain/compilers, and GRUB, that made certain, fragile assumptions regarding data structure alignments, linkbase addresses, stack-smashing protection, and MultiBoot structures, that are gradually becoming false, as newer versions eclipse them.
For instance, upstream Pistachio have known about https://github.com/l4ka/pistachio/issues/13, for a long time, but sadly, no fix is forthcoming. :(
The x86 code also uses a lot of AT&T Assembly, that CLang/LLVM refuses to compile, and assemble, so we end up being locked-in to a single compiler, and version.
Even though GCC is Open Source, and portable, there's no guarantee that older versions will always be buildable, with newer ones; and, although we could ship a VM/Docker image, with an old OS, and toolchain, we're responsible for its security, providing hosting of such huge files, and maintaining GPL compliance. That would also limit us to a single CPU architecture, which is a pain, since we also want to run on POWER/PPC/Cell, and probably also ARM/SPARC/RISC-V, in the future.
Annoyingly, over time, a lot of resources have just disappeared from the Web (especially the NICTA, and OKL4 stuff, and the L4Ka site, at KIT has a lot of broken links, now), so it's becoming harder to figure out the care, and feeding of such old code, in order to make a smooth transition to modern alternatives, which makes it imperative on Orion, to maintain copies of them, for future reference.