GNU branch

[mfld-fr]

Current version in switch-to-gnu branch is now able to login, execute some commands and run the ktcp & telnetd daemons. This issue tracks the remaining points to be addressed to reach an acceptable quality level :

• [x] BUG: Startup script not executed: FIXED in 4d36220d
• [x] BUG: All ASH built-in commands fail: FIXED in 93b57f47
• [x] Fixes the GCC warnings (1988 warnings left !): to be streamlined
• [x] Remove the unit test programs from the default configuration: DONE in 1e95f468
• [x] Rework the heap + stack space allocation in kernel execve: postponed to #241
• [x] Restore the heap + stack size parameter (previous ld86 -H option): postponed to #241
• [x] Wipe out the remaining DEV86 stuff: DONE in 7ea329d
• [x] Optimize the string functions (currently only in C): to be streamlined
• [x] Split the large objects file in LIBC to optimize the executable sizes: to be streamlined
• [x] Remove duplicated code between kernel and LIBC: postponed to #238
• [x] Restore the compression programs (need a GCC primitive): joined to #226
• [x] Rework the MINIX boot block: DONE in 9e038b8
• [x] BUG: cat reports false error 0:
  • wrong test of returned value in libc/system/syscall0.s: FIXED in e005026
  • wrong optimization of "comparison to 0" by GCC: FIXED in tkchia/gcc-ia16#40

[jbruchon]

I have long thought that removing the redundancy between the kernel and C library would be a great idea. I don't know what the best way to implement this would be though. The libc bits are statically linked into every program such that they're all stand-alone binaries and there is no support for shared libraries and dynamic loading which would make the task a breeze. How much of libc ends up in the kernel? It seems like the best route would be to add shared library support but that implies things like -fPIC which will make the code larger and slower. There seems to be no good solution I can think of.

What's this one? "Optimize the string functions (currently only in C)"

[mfld-fr]

I am thinking about a lower cost solution to share code between the applets than implementing the "shared object file" feature : moving the LIBC code for large functions like printf() to a standalone executable with only a code segment, restore the old "executable sticky bit" to make this executable to stay in memory, and using the interrupt vector 81h as a trampoline for such functions (same technique as for DOS extension modules).

The "Optimize the string functions (currently only in C)" is to restore the assembler implementation of some functions like memcpy(), that I temporarily disabled during the move to GCC.

[mfld-fr]

The switch-to-gnu branch is currently blocked because the MINIX bootblock (also known as minix.bin) is still built with dev86. Currently reworking that block... also an opportunity to simplify by directly loading the kernel from that block without the intermediate minix_elks.bin helper.

[mfld-fr]

Now unblocked after commit 9e038b8. Still a draft of a simplified boot process from the MINIX filesystem, with some limitations (only FD1440 supported, kernel size limited to 64K), but works well under QEMU (faster boot as intermediate 'minix_elks' boot helper was dropped).

[mfld-fr]

Submitted as #240.