KS2008: Kernel code with large user-space components

The direct rendering infrastructure (DRI) code has always played by different rules than the rest of the kernel. It is an out-of-tree project which has produced wildly different sets of APIs over the years. And it has never quite been as good as anybody would like. This recent LWN article covers some changes happening in the DRI camp. The unique nature of DRI can be traced back to the fact that much of the problem can only be solved in user space. At the 2008 kernel summit, graphics developer Dave Airlie led a session on "best practices" for the creation of kernel code which, like DRI, has large user-space pieces.

Dave says that developers for much of the kernel have an easy life; they can work toward the implementation of a well-defined interface which has been specified by POSIX for years. But some folks are not so privileged. In the graphics world, every device must expose a different interface to user space; every attempt to standardize these interfaces has produced highly ugly results. There is no standard here, and there is no real prospect of creating one.

Actually, that is not quite true; the standard for this kind of device is OpenGL. But there is little interest in putting a full OpenGL implementation into the kernel itself. So there has to be a wide channel of communication between user space and the kernel, and it will always be somewhat device-specific.

The DRI project develops its code outside of the mainline because stabilizing this user-space API is hard. The bulk of the code (90%) is in user space, and, until all that user-space code works, it is not at all clear that the interface with the kernel is correct. Once the code goes into the mainline, that API must be frozen. So DRI code will remain outside until the developers can be confident that the API has reached a stable state.

The other reason for out-of-tree development is the need to make life easier for testers. There are a fair number of people who are interested in testing graphics drivers, but who are not kernel developers. The DRI project wants to allow these testers to operate on a stable base - the kernel provided by their distributor, preferably - and not have to run bleeding-edge mainline kernels. So the DRI code has enough backward-compatibility code in it to allow it to run with a range of kernel versions. This code is not welcome in the mainline, so it must be removed before any DRI code is submitted upstream. But it must remain in the DRI tree, or the project will lose a lot of testers.

Dave had a couple of requests for the kernel development community. One of those was to be allowed to keep the backward compatibility code even when drivers are sent upstream. Compatibility would not have to be long term - three development cycles, perhaps - but the ability to run across that range of kernels would make life a lot easier. It would also eliminate the need for the DRI developers to rewrite the code immediately before submission to the mainline - a process which does not help to assure stable operation. There was not a lot of opposition to this idea. Linus did note, though, that the DRI developers have not been complaining about API changes which cause them trouble. His suggestion was that they let the community know when API changes create pain; perhaps some of those changes could be reworked to lower their impact on out-of-tree code.

The other request was to be allowed to put exports for kernel symbols into the mainline even though the code using those exports is not yet being merged. The presence of those exports would, again, make life easier for testers. This idea, too, drew no serious opposition. It was suggested that any such exports should be accompanied by a comment explaining why it exists and should not be removed.

---

(Log in to post comments)