Ghost Kernel

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.