Design Limitations To Tackle

Swapping

Because swap in occurs in the process context and the process may switch in during an interrupt we may do the swap in entirely with interrupts off. As our I/O subsystem is polled and many controllers have to disable interrupts anyway this is far less of an issue than on bigger systems. Fixing it probably requires fixing the IRQ return path logic. (IRQ return path and IRQ stacks fixed, testing swap fixes for the non single process in memory case - the single process case needs fork() dealing with as well)

It is also very hard to write a swap driver for a banked memory box because execution is occurring on the stack of the departing process. In order to write the new process into memory it is necessary to write to the top bank of the new process. To do that requires switching banks which means switching out the stack that is in use. (some infrastructure added, not yet all wired up and tested)

User and Kernel Contexts Are, In Places, Confused

Signal return in particular, both off the back of a syscall and off interrupt returns is a sort of hybrid space. It doesn't matter that much currently as the processors don't have that distinction (other than being a pain to debug) but will matter in order to sort processors like the 68008.

Now mostly sorted for Z80 and 6809 at least.

Scheduling

The task scheduling is overly simplistic. It needs to make a decision very fast on a slow processor. It also needs to minimise the switch rate. The current algorithm is to run niced processes for less time, which has exactly the wrong effect in terms of switch rate. This makes it the wrong lever to punish CPU bound tasks but at the same time we don't want to keep pre-empting and we absolutely cannot afford to do so when swapping is involved

Console Echo

Console echo is done on the interrupt path. This means that it races tty output. With classic UZI and a serial port this at worst meant losing a character and disabling interrupts over a couple of I/O operations. With video the situation is much messier but now has a sort of fix.

We cannot rely on a TX done interrupt for the serial case because a lot of hardware of that era doesn't have one.

[DONE] One possibility may be to implement some kind of deferred processing so that echo in an IRQ is processed by the video output logic if it was running during the interrupt. That means adding a minimal but new set of locking primitives to the core code.