Ghost Kernel

In an effort to get some proper painting I decided to port the cairo graphics library, which has advanced painting and nice performance. This made the UI a little bit faster in general. There are still some things to do (text fields must be fixed to work for cairo), but the overall experience with the library is great so far.

The obsolete messaging interface (g___send___msg, g___recv___msg, g___recv___topic___msg) was removed from the kernel. All applications that previously used it are now using the new interface that supports arbitrarily sized messages (g___send___message, g___receive__message).

Last but not least: I've been working a lot on a nice documentation using asciidoc, which will go online soon and be continuously updated and complemented.

I'm doing some work on the system documentation. For this I made a diagram that shows how filesystem transactions are working in Ghost. The following explanation applies to the read operation when a driver task is involved. Filesystem drivers in Ghost run in user space, therefore they run in their own task.

Basics

• a filesystem node has a delegate that has the implementation of the underlying filesystem operations (read, write, open etc.)
• a filesystem node is mapped to a process via a file descriptor
• the transaction store holds a status for each running transaction
• a waiter object is used to store waiting information for one task and decide whether a task shall keep sleeping during scheduling

Process visualization

Process explanation

1. requesting task creates the request structure and performs the read system call
2. the system call handler looks up the filesystem node for the given file descriptor
3. the system call handler creates a transaction handler that is responsible for keeping track of the transaction status and performing the requested operations
4. the transaction handler tells the delegate to start a transaction
5. the requesting task is put to sleep and a filesystem transaction waiter object is appended
6. the delegate starts a new transaction in the transaction store (retrieving the transaction id)
7. the delegate asks the driver task to perform the read operation
8. the delegate sets the transaction status to "waiting"
9. the driver task now does anything that is necessary to perform the read operation, like querying the hard disk etc.
10. the driver task sets the status of the transaction to "finished" once its done (using the fs-set-transaction-status-syscall)
11. the waiter object is continously checking the transaction store whether the transaction has finished. while the driver performs the transaction, the waiter tells the scheduler to keep waiting
12. once the transaction status is "finished" the waiter object tells the transaction handler to finish the operation
13. the transaction handler finishes the transaction by writing the result data into the requesting tasks request structure
14. the waiter is removed from the requesting task

The request object in the requesting task now contains the result of the operation.

Working on PCI, needed for using the ATA controller. One of the next bigger goals is hard drive support. PCI busses are now being scanned and the kernel stores information for all existing devices for later use.

I added interface named kernquery to the kernel. There are a lot of places in the system where various information from the kernel is needed. Creating a syscall for each one felt too bloaty, so I decided to add a kind of sub-interface that can be extended more easy and isn't that strict. It will be used for loading process information, process lists, get PCI device information and more.

Also implemented a small utility program kern which uses the new kernquery interface to print information. Here's a fancy listing of the PCI devices in the system:

(The little smiley on the bottom right is a bug lol)

I wrote a small calculator to test the UI interface of the window server. The application is all implemented in client side, using the API that the server provides.

It only does integer calculation at the moment though, because I was too lazy to implement strtod. :D Here's a little video of it in action. See the source code on GitHub to get an idea of how the UI API is used here.

The latest changes overall are a lot of improvements in the client-windowserver protocol, a login screen and some cleaning up in the terminal (occasional deadlocks fixed). Currently working on making the ramdisk filesystem writable to have a temporary storage, fixing the new scheduler implementation on multi-core systems (has some bugs), and then implementing a desktop application with nice little icons.

Merry christmas everyone! I'm not too busy developing during christmas time. Wish all of you nice holidays and a good slide into the new year. :-)

I added a nice little SSL certificate to the site, thanks to letsencrypt.org. Great project!

At the moment I'm still (re)working the window server. There are some issues with memory allocation in multithreaded applications of which I need to find the cause (this kind of sucked up my development time for quite some time now). Will post more updates when I have details.