This recent LWN article
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.
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
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
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.
to post comments)