List view
A real POSIX shell will be needed to run most build scripts, configure scripts and so on. I would really, *really* like to not have to write a shell so we need to port a real shell to Onramp. Unfortunately most shells use `fork()` pretty heavily which will make them difficult to port. For example the ash shell, which has popular derivatives dash and Busybox, uses `fork()` even just to parse here documents! Probably the best candidate for porting is [oksh](https://github.com/ibara/oksh) which prides itself on portability. It too uses `fork()` though; it will need some work to use something like posix_spawn() which we can implement, but I think upstream would be open to it in order to allow the shell to support devices without MMUs. If we can get a third party shell to work, I'll be confident that the majority of command line programs can be ported to Onramp with little difficulty. This will also make it possible to do just about anything in a freestanding Onramp environment.
No due date•1/2 issues closedThis milestone is to boot an x86 system from a tiny binary seed, and from there to bootstrap an entire system from pure handwritten source code. There are three big pieces missing: - A freestanding Onramp VM and hex tool. This will need multiple stages, including a 16-bit binary seed hex tool that fits in the MBR boot area, a VM, another hex tool, etc. - The Onramp shell. This is not yet implemented. We can reuse much of the code from ld/0, i.e. the file I/O buffering and such. We can also reuse the spawn code in libc/0 which is currently used by cc. - The stages of the Onramp OS. The first stage just needs to treat a tarball as a filesystem; we only need to implement the six filesystem syscalls (fopen, fclose, fread, fwrite, ftell, fseek.) Once these things are working, it should be possible to boot Onramp in freestanding. From there we can start porting other programs we will need to build Fiwix.
No due date•2/2 issues closedThe next major milestone for Onramp is to compile TinyCC. Most of my attention is currently focused on this goal. There are two major missing pieces: missing features in cci/2, and missing libc functionality. For cci/2, I'm a bit in the weeds because I need to make cci/2 emit an intermediate language so I can simplify it to add more features. For the libc, probably a lot of stuff is missing. The biggest is floating point support which needs to be software emulated. This is partially implemented. TinyCC will also require much more of printf() and probably scanf(), along with many other libc functions I'm sure. It will be easier to get a handle on what TinyCC is missing when the compiler can parse floats.
No due date•0/2 issues closed