User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

studentprojects:exceptionhandlingunification [2014/11/11 08:52] (current)
Line 1: Line 1:
 +===== Exception handling unification =====
 +(possible project)
 +Minix uses several ad-hoc mechanisms/​protocols to handle exceptions (e.g. pagefaults) and other events (e.g. timer ticks). Typically, this is based on first sending notification to the userspace process that should handle the event (the handler), which consequently request information from the kernel. Except interrupts everything happens because of the currently running process. Therefore it is possible for the kernel to generate message on behalf of the process and use the IPC mechanism (which already exists in the kernel) to block the process and deliver the data to userspace.
 +The current model requires per-event queues of process that wait for the handler to request the data from the kernel. The queues inherently serialize the processes. Moreover, sometimes the queue is rather a stack. Typically this mechanisms also assumes that the handler have priority high enough to run immediately. Also this makes impossible to have - Show quoted text - multiple handlers for the same type of events. Last but not least it also requires complicated process data structures in the kernel (process table).
 +As the notification which is sent by the kernel to the handler of the event is a normal message we could already include the data required to handle the event in case the data fit in the message (mostly true). For instance to resolve a pagefault, we can immediately include the faulting address and whether a read or write is the cause of the exception rather than letting VM to use an ad-hoc mechanism to request this information from the kernel after it receives the notification.
 +Although a single notification is sent in case the handler is not receiving, the assumption that the handler is able to run immediately makes the accumulation of notifies not realistic, in fact each event is a single notify. In such a case delivering the required data takes 2 context switches instead of 1 and extra data copies.
 +The goal of this project is to unify all these mechanisms in such a way that a message is sent on behalf of the faulting processes to the handler a mechanism to possibily to register different handlers for each process and create/​remove/​change system calls so that the handler can resume/​terminate/​change the execution of the faulting process.
 +The benefit of the proposed changes is simpler and smaller kernel code, most likely faster execution and possibility to move handling signals from kernel to userspace. This mechanism may also help to implement virtual machine monitors in userspace (unlike in e.g. Linux), however, this requires more data to be exported. Reusing the IPC mechanism to deliver the messages to the handlers also preserves the priorities (unlike the queues) which is highly preferable for real-time systems.
studentprojects/exceptionhandlingunification.txt · Last modified: 2014/11/11 08:52 (external edit)