Ghost Kernel

Canvas implementation, desktop application 2016/07/11, 17:08:20

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.


Version 0.5.3 - Demo image, Cairo rendering, new tools, documentation 2016/05/13, 15:05:32

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.


Cairo / Removed old messaging interface / Documentation 2016/04/09, 17:06:41

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.


How filesystem transactions work 2016/03/17, 15:48:21

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.


  • 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.


PCI device scanning, introducing 'kernquery' 2016/03/11, 21:55:25

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)