FreeBSD’s linuxkpi code is pretty clean and easy to work with. We shouldn’t incur a performance penalty here, as all the most performance-intensive functions (bus space access, etc.) are inlined anyway, so it’s just another layer of inlining the compiler has to do.
No, not really? Each driver/accelerant pair already has their own custom ioctl set besides the regular ones. Usually this is just ‘get private data’ or the like (as intel_extreme and radeon_hd do), but there’s no necessity it needs to be “just that.”
Wayland compositors often have a similar split like we do in app server vis-a-vis the server itself and the accelerants, though they typically call these backends. For instance, ee what wlroots does here. So we can just write a drm.accelerant that uses libdrm (which in turn ioctls the graphics devices directly) as an app_server backend.
So this model is very much like the way ethernet drivers ported from FreeBSD work on Haiku: They function almost like native ethernet drivers, but with more ioctls that you can use if you know about them. We can do the same thing for graphics drivers, which will allow us to keep our old modesetting drivers alongside these new DRM ones (and continue writing them, if we wanted), while also gaining 3D acceleration in a way that does not place a massive burden on us.
Gallium discovered that you really need the massive memory management stuff in the kernel; there’s just no way around that, which is why we’re at where we are now with DRM et al. being these huge hulking pieces of software that are usually over a hundred thousand lines of driver code for one chipset family. It’s just a mess.
FreeBSD, OpenBSD, and DragonFlyBSD all use the linuxkpi wrappers and are getting close to Linux levels of performance, so this model works for them, so they would likely be uninterested in a “lite” driver model. Maybe if we had more manpower we could experiment more, but we don’t, so we should take the more traveled path on this one.