| 3 | | It would be much more elegant to define a text-based language for expressing this symbolic instruction code. Thus the driver could express the pseudocode as a simple string literal that would be then converted to the binary form. The language could allow for named constants, which would make the code much more readable. |
| | 3 | Details:: |
| | 4 | Level-sensitive interrupts are tricky to handle especially in a microkernel-based operating system in which the device drivers run as userspace processes. The condition which triggered the interrupt must be cleared before the system is ready to receive another interrupt of the same kind (or the device immediately interrupts the system again), but only the userspace driver knows how to do it. This kind of a chicken-and-egg problem must be solved somehow. HelenOS achieves this in a portable way by letting the userspace driver inject a specialized byte code into the kernel. When an interrupt comes, the kernel uses the pseudocode to figure out whether the driver wants to accept the interrupt and also to clear the condition. |
| | 5 | |
| | 6 | IRQ pseudocode in drivers is typically written as a C initializer (array of structs with designated members). This is not very concise/elegant. What's worse, often we need to substitute constants representing various physical addresses into the code, which is done by patching the individual pseudocode instructions at run time by hand. |
| | 7 | |
| | 8 | It would be much more elegant to define a text-based language for expressing this symbolic instruction code. Thus the driver could express the pseudocode as a simple string literal that would be then converted to the binary form. The language could allow for named constants, which would make the code much more readable. |
| | 9 | |
| | 10 | What Gains and Benefits will this bring?:: |
| | 11 | It will be easier and more comfortable to write the interrupt-handling part of each driver. The pseudocode will be much more readable and there will be fewer programming errors. |
| | 12 | |
| | 13 | Difficulty:: |
| | 14 | Depending on the devised language, the difficulty will range from easy for an assembly-like language to medium and difficult for a more C-like language, such as the one suggested [#comment:2 here]. |
| | 15 | |
| | 16 | Required skills:: |
| | 17 | A successful applicant will have good skills of programming in the C language and the ability to use both the current and the devised language for writing HelenOS IRQ pseudocode. In case of a more sophisticated language, the candidate shall also have an understanding of grammars and various compiler construction techniques. |
| | 18 | |
| | 19 | Documentation:: |
| | 20 | * [browser:/mainline/uspace/drv/nic/ne2k/ne2k.c#L76 Example of the current IRQ pseudocode in the NE2000 driver] |
| | 21 | * [#comment:2 Example of possible IRQ pseduocode description language] |
| | 22 | * [wiki:DeviceDrivers Writing Device Drivers for HelenOS] |
| | 23 | |
| | 24 | Possible mentors:: |
| | 25 | HelenOS Core Team, Jiri Svoboda, Jakub Jermar |
