Ghost Kernel

After debugging for many hours, I finally got the canvas implementation to work nicely. It is now possible to perform drawing on a free canvas from any application. This is implemented using shared memory between applications and the window server.

The new canvas implementation finally allowed me to add a GUI mode for the terminal!

Here's a little video of it in action. It's still a bit laggy though :o)

The latest commit includes a canvas implementation and the first steps for an actual desktop.

A canvas component is needed to allow applications to freely draw on a buffer in memory, which is usually only done by window server. The use case for this canvas is for example drawing a task-bar from within the desktop application or providing a space to draw images from client-side. It will also be the basis for other user-drawn components.

Unlike other UI components, the content of a canvas is entirely rendered by the component creator instead of the server. The implementation for this is done with a combination of shared memory and messaging. The client requests creation of a canvas component just as with any other component, and the window server notifies the client with events when the buffer has been allocated.

The most challenging issue with a shared memory buffer is avoiding the client application to cause faulty memory accesses when the buffer needs to be resized (i.e. after relayouting). This is now solved by simply retaining the previous buffer until the client application sends an acknowledge message to the window server. This consumes more memory until the buffer is acknowledged but improves stability. A nice little discussion on this topic was led in the OSDev forums.

This release contains a whole bunch of new features and improvements. The window server rendering backend has been completely rewritten and now uses the cairo graphics library. Overall stability has been improved with various changes to the kernel.

Try it out yourself! Get the demo image.

The new sources are available on GitHub. I started writing a documentation that is in the repository too and be compiled using ASCIIDoc, for those who are interested in technical details of the 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.