Linux_Kernel_Driver
- Edit
- Recent Changes
- Advanced Search
- All Pages
- Administration
- Index
Linux_Kernel_Driver 
After beginning work 
on a PiTrex driver module for the Linux kernel, the following pros and cons to the approach (compared with the current hack of disabling system interrupts from user-space for the entire duration of the Vectrex display update) were realised. Further work on the driver is currently suspended, though advice/contributions are welcome.
See Linux_Configuration for background info. Also Interrupts.
Pros and Cons
Pro: Less "hacky" interrupt disabling using the kernel's interrupt disabling code, so should be more portable between different Pi versions.
Con: Doesn't eliminate the need to disable interrupts while executing the drawing code. Still need specific, non-standard, Linux config. to prevent "wobbles"
Pro: Allows game code to run during line drawing wait (#RAMP asserted)
Con: Needs to be recompiled (against the kernel source code) for each new kernel version. (Technically you might be able to force wrong versions to load and get away with it, but it might cause sudden kernel death)
Pro: Using the Fast Interrupt Request (FIQ) may be another backup option if hrtimers doesn't work.
Con: Hard to ensure that delays can't happen as a result of slow system interrupt processing, or the scheduler "jumping in" between the end of a timer interrupt and all interrupts being disabled.
Pro: Presents an established interface for communicating from other processes, akin to things like the Linux framebuffer device.
Pro: May avoid the need to run PiTrex games as root, if all privileged I/O operations outside of displayPipeline are replaced with ioctl calls.
Con? Don't know whether interrupt disabling from the kernel messes up the system clock, or whether "ticks" actually do still happen.
Con? Don't know whether disabling interrupts from within an interrupt handler will work, or is supported such that it won't break and be unfixable in a later kernel version.