This page contains information regarding the testing techniques.
Students are very strongly encouraged to thoroughly test their implementation locally before relying on the kaneton test system.
In order to test a kaneton implementation manually, students should set up their own tests suite consisting of many tests targeting specific functionalities.
Students should pay extensive care to the threads and tasks testing since these are the most difficult kernel components to make work in every circumstances.
Regarding threads, students must remember that kernel, driver, service and guest classes have different hardware privileges; kernel threads should thus be preferred.
Noteworthy is that, in order to test tasks, the student has two solutions. The first one consists in creating a normal task, with its own address space and code, being either an external ELF loaded in memory or a portion of the kernel code for instance. The latter consists in creating a task sharing its address space with the kernel. The advantage of this last solution is that the kernel functionalities can be used including allocating memory dynamically, displaying information, manipulating the scheduler and so forth. Unfortunately, this solution does not test the task creation thoroughly. One might therefore rely on the first technique, creating a completely independent task and then make it communicate with the kernel by passing data through a shared segment for instance.
Once the implementation has been tested locally, one may want to test it against the official tests suite. For that, students, depending on their status, should have been provided a test capability enabling them to trigger the test system's suites.