has long been working toward improved 3D
graphics support in free operating systems. It is a crucial part of the
desktop Linux experience, but, thus far, DRI development has been done in
a relatively isolated manner. Development process changes which have the potential
to make life better for Linux users are in the works, but, sometimes,
that's not the only thing that matters.
The DRI project makes its home at freedesktop.org. Among other
things, the project maintains a set of git repositories representing
various views of the current state of DRI development (and the direct
rendering manager (DRM) work in particular). This much is not unusual;
most Linux kernel subsystems have their own repository at this point. The
DRM repository is different, though, in that it is not based on any Linux
kernel tree; it is, instead, an entirely separate line of development.
That separation is important; it means that its development is almost
entirely disconnected from mainline kernel development. DRM patches going
into the kernel must be pulled out of the DRM tree and put into a form
suitable for merging, and any changes made within the kernel tree must be
carefully carried back to the DRM tree by hand. So this work is not just
an out-of-tree project; it's an entirely separate project producing code
which is occasionally turned into a patch for the Linux kernel. It is
not surprising that DRM and the mainline tend not to follow each other
well. As Jesse
Barnes put it recently:
Things are actually worse than I thought. There are some fairly
large differences between linux-core and upstream, some of which
have been in linux-core for a long time. It's one thing to have an
out-of-tree development process but another entirely to let stuff
rot for months & years there.
The result of all this has been a lot of developer frustration, trouble getting code merged, concerns that the
project is hard for new developers to join, and more. As the DRM
developers look to merge more significant chunks of code (GEM, for example), the pressure
for changes to the development process has been growing.
So Dave Airlie's recent announcement
of a proposed new DRM development process did not entirely come as a
surprise. There are a number of changes being contemplated, but the core
ones are these:
- The DRM tree will be based on the mainline kernel, allowing for the
easy flow of patches in both directions. The old tree will be no
- A more standard process for getting patches to the upstream kernel
will be adopted; these will include standard techniques like topic
branches and review of patches on the relevant mailing lists.
- Users of the DRM interface will not ship any releases depending on DRM
features which are not yet present in the mainline kernel.
The result of all this, it is hoped, will be a development process which is
more efficient, more tightly coupled to the upstream kernel, and more
accessible for developers outside of the current "DRM cabal." These are
all worthy objectives, but there may also be a cost associated with these
changes resulting from the unique role the DRI/DRM project has in the free
There is clearly a great deal of code shared between Linux and other free
operating systems, and with the BSD variants in particular. But that
sharing tends not to happen at the kernel level. The Linux kernel is vastly
different from anything BSD-derived, so moving code between them is never a
straightforward task. GPL-licensed code is not welcome in
BSD-licensed kernels, naturally, making it hard for code move from Linux
to BSD even when it makes sense from a technical point of view. When
code moves from BSD to Linux, it often brings a certain amount of acrimony
with it. So, while ideas can and do move freely, there is little sharing
of code between free kernels.
One significant exception is the DRM project, which is also used in most versions
of BSD. One of the reasons behind the DRM project's current repository
organization is the facilitation of that cooperation; there are separate
directories for Linux code, BSD code, and code which is common to both.
Developers from all systems contribute to the code (though the BSD
developers are far outnumbered by their Linux counterparts), and they are
all able to use the code in their kernels. When working in the common code
directory, developers know to be careful about not breaking other systems.
All told, it is a bit of welcome collaboration in an area where development
resources have tended to be in short supply - even if it benefits the BSD
side more than Linux.
Changing the organization of the DRM tree to be more directly based on
Linux seems unlikely to make life easier for the BSD developers. Space for
BSD-specific code will remain available in the DRM repository, but turning
the "shared-code" directory into code in the Linux driver tree will make
its shared status less clear, and, thus, easier for Linux developers to
break on BSD. Additionally, it seems clear that this code
may become more Linux-specific; Dave Airlie says:
However I am sure that we will see more of a push towards using
Linux constructs in dri drivers, things like idr, list.h, locking
constructs are too much of a pain to reinvent for every driver.
Much of this functionality can be reproduced through compatibility layers
on the BSD side, but it must carry a bit of a second-class citizen feel.
Dave has, in fact, made that state of affairs clear:
The thing is you can't expect equality, its just not possible,
there are about 10-15 Linux developers, and 1 Free and 1 Open BSD
developer working on DRM stuff at any one time, so you cannot
expect the Linux developers to know what the BSD requirements are.
The fact that fewer people will be able to commit to the new repository -
in fact, it may be limited to Dave Airlie - also does not help. So FreeBSD
developer Robert Noland, while calling this proposal "the most fair" of any
he has heard, is far from sure that he will
be able to work with it:
I am having a really difficult time seeing what benefit I get from
continuing to work in drm.git with this proposed model. While all
commits to master going through the mailing list, I don't
anticipate that I have any veto power or even delay powers until I
can at least prevent imports from breaking BSD. Then once I do get
it squared away, I'm still left having to send those to the ML and
wait for approval to push the fixes. I can just save myself that
part of the hassle and work privately. If I'm going to have to
hand edit and merge every change, I don't see how it is really any
harder to do that in my own repo, where I'm only subject to FreeBSD
On the other hand, it's worth noting that OpenBSD developer Owain Ainsworth
already works in his own repository and seems
generally supportive of these changes.
Given the difference between the numbers of Linux-based
and BSD-based developers, it seems almost certain that a more
Linux-friendly process will win over. There is one rumored change which
will not be happening, though: nobody is proposing to relicense the DRM
code to the GPL. The DRM developers are only willing to support BSD to a
certain point, but they certainly are not looking to make life harder for
the BSD community. So they will try to accommodate the BSD developers
while moving to a more Linux-centric development model; that is how things
are likely to go until such a time as the BSD community is able to bring
more developers to the party.
to post comments)