Linux port?

A port is begun, but barely. We are still beating the compiler/specializer tool chain into shape, and have started implementing syscalls as outcalls to the host so that apps (such as benchmarks) have a file system to use. Some of those syscalls are native rather than outcalls; an example is the timing/clock facility. The next step down that path is to fill in libc and libc++. We don’t see any issues with that, just a lot of bug-catching.

Moving the OS from host to native is somewhat separate from this effort to get apps to work. There are three major parts involved: a BIOS, a microkernel, and Linux. However, when you look at it as an implementations the task partitions differently: hardware-integrated system support (primarily memory management – PLB, TLB and its tables, but some spiller) that must be native; I/O (enough native to let drivers work, but the actual devices have to be host-side or a whole new piece of simulator); and the load end of the tool chain (linkers, loader and debuggers).

The expectation is that by the time the system can run an open-source BIOS and microkernel then a microkernel-based version of Linux (we still lean toward L4) will slide in on top relatively easily.

As for the timing of all this: as you know, we are a sweat-equity company and most of us are part-time and irregular, so planned schedules are impossible. We are actively seeking engineers who would like to help and earn a piece of the Mill, and have many openings. Interested?