Aside from coming up with ideas for “release engineering” there are a few parts of the OS which are currently under heavy development and may or may not be ready in time for the first proper releases:
PLIC & Driver Kit
The system currently only supports some ad-hoc hardware drivers for testing, but does support loading Device Tree Blob files so can be extended to support real hardware drivers with a bit more work:
- PLIC & interrupt handling code needs to be extended or rewritten to allow dynamic configuration from the DTB
- Management of modules & drivers is not fully fleshed out yet, but is likely to work similarly to other systems (e.g. “device files” are still used currently with limited functionality but could be streamlined into a more modern configuration)
- Alternative filesystems, advanced disk management and partitioning support will probably be delayed until after some releases or released with limited functionality (prioritising enhancements to the core filesystem instead to ensure it remains stable)
- Framebuffer graphics can easily be added for some (emulator) targets but will likely be more problematic on real hardware
- No work has commenced on any support for device hub technologies such as PCI & USB, support for legacy device hubs will probably be limited for a little while in favour of drivers for smaller individual devices & GPIO
Full Self-Hosting
The system is already quite stable when built with the custom compiler, but more work is needed especially on the assembler/linker and at the build system end in order for the OS to be able to fully recompile itself.
In the meantime most development is done from Linux, which is a reasonable compromise and is the same way most other operating systems are developed, but the system is fairly close to being self-hosted and this is expected to go very smoothly once the new linker rewrite is finished.
Networking Support
I’ve been looking into a few different options to provide networking support, none of these options are perfect so the final system may come with a couple of alternatives but these probably won’t be ready in initial releases:
- Writing a new TCP/IP stack – this is likely to be viable for small demos but is unlikely to result in a competitive system in the short term
- Porting an existing TCP/IP stack – this is likely to be much more practical but will probably be limited to some typical “embedded networking” feature set and perhaps a bit clunky to set up for end users
- Developing new protocols – this will likely result in a much better demonstration systems and perhaps will be more useful for fully integrated products (especially for HPC & robotics) but won’t integrate nicely with legacy tech
- Running full networking using virtualised/emulated systems – this will probably be a good compromise for full featured networking in the mid term but won’t solve short or long term integration problems
For the time being, some legacy internet APIs including kqueue/kevent functions are already exposed in the C library but aren’t implemented in the OS, allowing some networked programs to be built or prototyped using legacy APIs but they won’t run on the new kernel yet.
Documentation & End User Utilities
Documentation is currently limited and no man (manual page) program is included. This will be addressed as individual components stabilise, in the meantime you will need to check instructions printed by the individual programs or written in the source code.
Some other utilities needed by users but not critical for development will also have been overlooked at this stage, but more programs can easily be ported later.
Leave a Reply