This page is intended to list a whole bunch of things which could/should be done, or will be done, to the RISC OS 5 kernel. Some items will make things better from the user's perspective, while others are just to help OS developers. * (Enhancement, ARMv6+) "Use the dual page table pointers to implement more efficient task swapping":https://www.riscosopen.org/forum/forums/3/topics/6351 * (Enhancement, ARMv6+) Write an abort handler to emulate ARMv5 rotated load behaviour. This will hopefully fix the majority of ARMv6/v7 compatibility issues. "See here":http://www.riscosopen.org/forum/forums/3/topics/207#posts-1223 for more info, or "here":http://www.riscosopen.org/forum/forums/3/topics/207?page=2#posts-3704 for current status. * (Enhancement, ARMv6+) Update system dynamic areas, kernel workspace, etc. to be non-executable where relevant, to reduce the damage that malfunctioning code can cause * (Bugfix) Heap corruption can cause CheckForNullAllocn to get stuck in an infinite loop. It would be nice if the code could detect the infinite loop, even if the heap corruption means there's little chance of the OS recovering (or even being able to report the occurence to the user) * (Enhancement) We need a way to allow HAL_CounterDelay to use WFI, or we need to introduce a proper high resolution timer which programs can use instead of calling the HAL directly (especially since there's currently no control over allocation of HAL resources to programs) * (Enhancement) Improve the data abort (and abort on instruction fetch) error message to make use of the DFSR/IFSR to provide a more descriptive error. E.g. reporting that something is an alignment fault instead of an ordinary abort. * (Enhancement) New OS_Heap reason code to allocate from the high end of the heap, to avoid fragmentation caused by temporary allocs? * (Bugfix) "The VDU PreGrow handler temporarily leaves some pointers pointing to bad memory, resulting in infinite abort loops if something tries VDU output while screen memory is being resized/moved":/forum/forums/4/topics/333 * (Enhancement) Lift the restriction that CMOS is always on bus 0 by extending the NVMemoryIICAddress API to return a bus number too. * (Enhancement) Extend the [[OS_IICOp]] API to negotiate speed with the HAL, for those platforms that can support variable speed.