OSNews

The DRM drivers are not an abstraction layer. The interface from each driver is different depending on the chip family. So I believe DRM/mesa does qualify as an exokernel design.

The layers look like this. libGL, common API for all to use. DRI, user space code that is specific to the chip family being supported. DRI and libGL are usually linked into the same shared object since most people only have one video card. This does not have to be done and it wasn't done a few years ago.

Finally there is DRM which is the kernel space driver. There are about 30 common DRM ioctls which control standard things like file handles and enabling interrupts. But you can't draw anything with the common ioctls. Next there are from 10 to 50 chip specific ioctls which control the meat of the hardware.

libGL (mesa) implements all drawing functions in software. The DRI libraries replace libGL functions with hardware accelerated ones if the hardware is capable. If a function can't be accelerated it falls back to the software implementation since it hasn't been replaced.

The ATI radeon family is a special case. There is one radeon DRM module since the core of all the radeon chips is very similar. But there are three DRI implementations R100, R200 and R300. The DRM driver sets up the DMA queue, but the commands that user space writes to the queues is different in each DRI driver.

Security is a problem. The DRM drivers need to scan the DMA commands to make sure no one is using the DMA hardware to peek at memory not owned by the calling process. Remember that DMA works on physical memory pages and can scan any of them. If you can get to arbitrary memory you can always gain root priv. To address this problem AMD is doing IOMMUs. Hypervisors hit this problem too.