Ghost Kernel

After being inactive for a pretty long time (sorry :) I've recently refactored quite some parts of the system.

The wait handling has been extensively reworked so that sleeping an waiting for file I/O is way more efficient now. The scheduler was slightly improved with this change as well. I also added support for the legacy PIC again since all the code was there, so it works without the IO/APIC activated.

Many dumb performance bugs in the window server have been fixed. Here's something for the eye:

Currently I'm thinking about porting to x86_64 and supporting UEFI.

We'll see. :-)

With the latest commits, C++ runtime features (most notably exceptions) and thread-local storage are now supported in executables and shared libraries.

The toolchain build was modified so that the shared version of libgcc libgcc_s.so.1 is now built. Using -shared-libgcc as a linker flag will now cause libgcc to be linked dynamically and therefore allow exception handling over multiple shared objects.

I've adapted the test suite to now call a runtime test program that performs multiple tests for global constructors, exception handling and TLS.

With those additions, shared library support should now be sufficient to continue work on other parts, most notably inter-process messaging will next be implemented in the new kernel implementation.

I've finally implemented basic support for shared library objects in the kernel's elf32 loader. This can be found in the branch dynamic-linking.

The main motivation for this was improving the size of executables and as a preparation for future performance improvements. The current implementation always binds all symbols early (so it behaves as if LD_BIND_NOW was set), so lazy-linking is not yet in use.

With this change, the build processes of libc, libghostapi and libuser where also adapted so they additionally emit .so files. By default the system libraries libc and libghostapi will therefore now be linked shared. The "cocorun" demo program is used to test out various features now.

The next steps are getting support for thread-local storage when such a variable is provided or accessed by a shared library. In the existing implementation, the TLS segment of the main object is loaded and a copy of that TLS master is assigned to each thread. There is some work left to do when working with shared libraries now, because each loaded ELF object can have a TLS segment and TLS relocations which must be fulfilled. For this the process structure must be adapted so that all of this information can be stored and evaluated later on.

Anyway, not much to see but have a look at this nice little shared library call :-)

The redux branch has now support for kernel-level threads and threaded system calls. The previous implementation only supported userspace-threads which had some advantages but also made specific call implementations more complicated. This approach will improve efficiency and allows a better scheduling implementation in the long run.

There were some interesting problems to solve; due to the fact that a kernel thread might get interrupt while holding a kernel lock, the g_mutex implementation must now keep track of the number of locks held per processor. As long as a task holds kernel locks, no other task will be scheduled until the task is finished with its work.

System calls can now be registered as threaded or direct calls. When a threaded call is executed, the respective handler is called within a kernel-level thread. These processing tasks are reused for successive system calls by the same task. This allows preemption during call processing and avoids blocking the scheduler for long-running requests.

The documentation can now be found here. It will be regularly updated from the GitHub repository.

Some parts where already updated to match the redux branch, but some parts are also mostly relevant for the existing code.

If you are interested in building Ghost by yourself, there are now instructions available.