Some new thoughts on NEUOS

Current version of NEUOS contains many design problems, I will list them below

1. Handmade bootup process now it use a custom hand-made bootloader that can only boot from floppy and harddik(maybe no hdd suport, I forgot) It will have problem booting up on bare metal. To ensure the bootloader works correctly even if run directly on bare metal, we need to use standard bootup process. Such as multiboot, for example grub. May be we will support EFI bootup
2. Messy build system NEUOS now using Makefile alone to build the whole system, which is impractical for a normal C project. We need to use auto build systems, such as automake, kernel now using kconfig system, maybe we can learn from it. Also, we could add support for configurable build options, (for example kernel .config file) to allow users to build flexible customized image
3. Lack of core function Currently, NEUOS supports following functions
   • multiprocess
   • paging
   • VGA and Serial Output
   • Keyboard IO
   • kernel syscall interface
   • scheduling and timer
   • some libraries

However these functions are not enough for a real operating system. At least the following funtion should be added:

• Virtual Filesystem Support
• exec syscall support
• (not part of kernel) A minimal shell should be supported
• char / block device Moreover, it will be better if we can support following functions
• networking
• advanced file system such as ext4
• green thread support
• media driver support (such as audio) P.S. These are very hard works and need tremendous time and efforts :(
• multi-architecture support ( we need to consider it at first so that we can add different arch support later)

4. Hard and unnecessary coding for students. Many students are not familiar with AT&T assembly or the Intel Manual. Some assignments such as hardware init and floppy IO now require them to write in full AT&T assembly, thus make them frustrating. Learned from AIM-public, these unnecessary but complicated code need to be implemented by the NEUOS developer, and provide API to students, they could just use the API to issue disk IO commands, hardware init, etc. And for a cleaner codebase, we need to remove the hand-written assembly as much as possible, instead, use C inline assembly as an alternative.

5. More formal debugging, cross building toolkit We now combined QEMU gdb and Bochs GUI together to debug the project, but these methods are not enough, for example we need to have some internal debug tool, debug function. And the toolchain for building NEUOS should be universal, from a specific architecture and ELF format, everyone can build NEUOS from its own toolchain, providing a Virtual Machine image is not a good choice for environment setup.

6. To be continued