Support for certain classes of hardware has often been problematic for the
Linux kernel, and 3D graphics chips have tended to be at the top of the
list. Over the last few years, through a combination of openness at Intel
and AMD/ATI and reverse engineering for NVIDIA, the graphics problem has
mostly been solved - for desktop systems. The situation in the
fast-growing mobile space is not so comforting, though. As can be seen in
recent conversations, free support for mobile graphics looks like the next
big problem to be solved.
At a first glance, the announcement of a 2D/3D driver
for Qualcomm "ES 3D" graphics cores (found in the Snapdragon processor
which, in turn, is found in a number of high-end smartphones) seems like a
good thing. Graphics support for this core is one of the binary blobs
which is necessary to run Android on that processor, and it seemed like
Qualcomm was saying the right things:
I'm writing this email because we think it is high time that we get
off the bench, into the game and push support for the Qualcomm
graphics cores to the mainline kernel. We are looking for advice
and comment from the community on the approach we have taken and
what steps we might need to take, if any, to modify the driver so
it can be accepted.
Advice and comment is what he got. The problem is that, while the kernel
driver is GPL-licensed, it is only a piece of the driver. The code which
does the real work of making 3D function on that GPU runs in user space,
and it remains locked-down and proprietary. Dave Airlie, the kernel
graphics maintainer, made it quite clear
what he thinks of such drivers:
We are going to start to see a number of companies in the embedded
space submitting 3D drivers for mobile devices to the kernel. I'd
like to clarify my position once so they don't all come asking the
If you aren't going to create an open userspace driver (either MIT
or LGPL) then don't waste time submitting a kernel driver to me.
Dave's message explains his reasoning in detail; little of it will be new
to most LWN readers. He is concerned about possible licensing issues and,
at several levels, about the kernel community's ability to verify the
driver and to fix it as need be. Dave has also expressed his
resentment on how the mobile chipset vendors are getting great value
from Linux but seem to be entirely unwilling to give back to the kernel they
have come to depend on so heavily.
This move may strike some people as surprising. There has been a lot of
pressure to get Android-related code into the mainline, but now an
important component is being rejected - again. The fact that user-space
code is at issue is also significant. The COPYING file shipped with the
kernel begins with this text:
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal
use of the kernel, and does *not* fall under the heading of
Normally, kernel developers see user space as a different world with its
own rules; it is not at all common for kernel maintainers to insist on free
licensing for user-space components. Dave's raising of licensing issues
might also seem, on its face, to run counter to the above text: he is
saying explicitly that closed user-space graphics drivers might be a work
derived from the kernel and, thus, a violation of the GPL. These claims
merit some attention.
The key text above is "normal system calls." A user-space graphics driver
does not communicate with its kernel counterpart with normal system calls;
it will use, instead, a set of complex operations which exist only to
support that particular chipset. The kernel ABI for graphics drivers is
not a narrow or general-purpose interface. The two sides are
tightly coupled, a fact which has made the definition of the interface
between them into a difficult task - and the maintenance of it almost as
hard. While a program using POSIX system calls is clearly not derived from
the kernel, the situation with a user-space graphics driver is not nearly
It should also be pointed out that, while the kernel community does not
normally try to dictate licensing in user space, that community has also
never felt bound to add interfaces for the sole use of proprietary code.
The resistance to the addition of hooks for anti-malware programs is a
But licensing is not the only issue here.
In a sense, user-space 3D graphics drivers are really kernel components
which simply happen to be running in a separate address space. They
necessarily have access to privileged functionality, and they must
program a general-purpose processor (the GPU) with the ability to easily
hose the system. Without the user-space component, the kernel will not
function well. Like other pieces of the kernel, the full 3D driver
must be carefully examined to be sure that there are no security problems,
fatal bugs, or portability issues. The kernel developers must be able to
make changes to the kernel-side driver with full knowledge of what effect
those changes will have on the full picture. A proprietary user-space
driver clearly makes all of this more difficult - if not impossible.
User-space binary blob drivers also miss out on many of the important
benefits of the free software development process. They will contain bugs
and a great deal of duplicated code.
What Dave (and others) are clearly hoping is that, by pushing back in this
way, they will be able to motivate vendors to open up their user-space
drivers as well. The history in this regard is encouraging, but mixed.
Over time, hardware vendors have generally come to realize that the value
they are selling is not in the drivers and that they can make their lives
easier by getting their code out into the open. What did it gain all of
those wireless networking vendors to implement and maintain their own
802.11 stacks? One can only imagine that they must be glad to be relieved
of that burden. But getting them to that point generally required pressure
from the kernel development community.
Hopefully, this pressure will convince at least some mobile 3D vendors to
open up as well. That pressure would be increased and made far more
effective if at least some device manufacturers would insist on free
software support for the components they use. There are companies working
in this area which make a lot of noise about their support for Linux. They
could do a lot to make Linux better by insisting on that same support from
Over the years, we have seen that pushing back against binary-only drivers
has often resulted in changes for the better; we now have free support for
a lot of hardware which was once only supported by proprietary drivers.
Some vendors never relent, but enough usually have that the recalcitrant
ones can simply be routed around. One shudders to think about what our
kernel might look like now had things not gone that way. The prevalence of
binary-only drivers in the mobile space shows that this fight is not done,
though. 3D graphics drivers are unique in many aspects, including their
use of user-space components. But, if we want to have a free kernel in the
coming years, we need to hope that they will be subject to the same
Comments (97 posted)
It should come as no big surprise that a large part of what we do here at
LWN involves web browsing. We are, after all, a web publication, and many
of our sources and other information come from various places across the web,
so we tend to spend a lot of time using a web browser. When Mozilla
availability of the first beta of Firefox 4 on July 6, it seemed like a
perfect opportunity to take the new browser for a spin.
One of the biggest—most visible—changes is the overall
browser user interface. For Linux and Mac users, though, those UI changes have
not yet been made, though some of the new functionality can be seen. By
using the "Tabs on top" selection in the View -> Toolbars menu, something of limited
preview of the new Firefox look can supposedly be achieved. Based on the descriptions
from Windows users, though, there is much more to the changes than just
moving the tabs. Full-screen mode in Firefox 4 (FF4) may
give a better preview to what the default look will be: tabs all the way at
that hide themselves when they aren't needed.
In any case, the UI is only one part of the changes that come with FF4.
Another important addition, at least for some folks, is the ability to play
HD-quality video in the browser using Google's new WebM format. In my
testing of the beta, videos seemed to work reasonably well—at least
as well as they do using Flash in Firefox 3.5—but only at 360p. It
may have been
a bandwidth problem at this end, but 720p videos played poorly, if at all.
It should be noted that the Flash version of the YouTube videos also
suffered from some playback problems at 480p in FF4, but didn't seem to in
On the other hand, in nearly a full day's worth of web surfing, FF4 was quite
solid, unlike 3.5 which seems plagued by some kind of hang that happens
more-or-less daily. I've always suspected Flash as the culprit, but never
narrowed it down to that for sure. One of the more interesting new
features in FF4 is crash
protection. The crash protection feature is meant to disable a
misbehaving plugin after it becomes unresponsive for 45 seconds by default.
As far as I could tell, that never occurred on any of the pages visited
with FF4. In the end, though, there were no crashes or hangs in five or
more hours of pretty continuous use, which makes for a pretty stable beta
in my book.
Another nice addition to the UI (one that Linux users do get to see
in the beta) is turning the "Addons Manager" into a full-fledged tab,
rather than a small pop-up window. It makes for much easier interaction
when installing, updating, and configuring addons and plugins. One wonders
if Preferences will eventually go that route, as the relatively small tabbed
window that is used currently has gotten pretty cluttered. A
reworking along the lines of the new Addons Manager would be welcome.
Installing the beta was completely straightforward: download a tar file,
untar it, and type ./firefox. It picked up the settings,
bookmarks, and so on from my current yum-installed version and,
crucially, didn't rewrite those files in such a way that the older version
could no longer read them. It is a well-behaved guest and, based on its
performance so far, could easily become my default going forward. Undoubtedly,
typing that will
doom me to some horrible, unrecoverable crash right in the middle of
pushing out this
week's edition—luckily I have the laptop as a fall-back position.
There are lots of little things that will come in handy. Changes have been
made to stop the CSS browser
history leak by altering
boon for anyone concerned about privacy in their browsing history. There
is a new "Heads Up Display" that will be useful to web developers. It
looks very similar to the console provided by the ever-useful Firebug addon. And so on.
Mozilla is making a big push to get feedback on
FF4. By default, the Feedback addon is installed, which puts a prominent
button in the upper right. The two main choices ("Firefox Made Me
Happy/Sad Because...") take you to a page to quickly fill out information
about what worked or didn't. One can also include the URL of a misbehaving
web site into
the report. It is a quick, nearly painless way to report problems (or give
kudos) on the beta.
One of the things that the Mozilla folks concentrated on with FF4 was
performance. Firefox has, somewhat deservedly, gotten the reputation of
being slow, and that is something that the development team is working very
hard to change. There are numerous improvements in FF4 to speed up the
browser, but I didn't find them to be particularly noticeable. While I use
the browser constantly, it may well be that I don't push it as hard as
others, or perhaps am more forgiving. In any case, FF4 certainly didn't
seem slower than its predecessors; maybe over time the performance
increase will become more evident.
Other than certain addons not (yet, presumably) being available for FF4, I
could pretty easily make the switch, which is a little surprising to me. Other
reports have found FF4 to be much less stable than I did. In any case, it
seems that Mozilla is on the right track with a fairly large incremental
update to its browser. FF4 is scheduled to be released late this year and
it looks to be a great browser to head into 2011 with.
Comments (19 posted)
In 2005, the Debian project voted to declassify
messages on the debian-private mailing
list after a period of three years. That is easier said than done, apparently. The General Resolution (GR) calls for volunteers to do the work of declassification, and few Debian Developers seem eager to do the work required to make it happen.
The debian-private list is, as the name suggests, a non-public list that is used by Debian Developers to discuss issues without the prying eyes of users, press, or anyone else outside the Debian project. The list and archive is only available to Debian Developers, and anything sent to debian-private is not to be spread to other lists.
Former Debian Project Leader (DPL) Steve McIntyre says that the traffic on debian-private "varies quite a lot, from a couple of dozen messages in some months to hundreds in others," depending on whether there's a large and sensitive discussion. But most of the traffic is mundane, according to McIntyre:
Most of the traffic is quite boring these days: vacation messages as you've heard about, plus related discussions. We do have occasional sensitive discussions where, for a variety of reasons, people would rather not have them in public: discussions about relationships with upstream developers, people joining or leaving the project, etc. Normally nothing too juicy, I'm afraid, but it's often kept private to avoid offence as much as anything else.
Plus, as you'll see on a lot of geek mailing lists and newsgroups, there's quite a tendency to wander totally off-topic or into humour. And then a similar amount of stuff from people asking "why is this on -private?" Quite boring, really...
The GR to declassify was put forward by Anthony Towns prior to his stint as DPL, with an amendment proposed by Daniel Ruoso. Towns' GR called for a volunteer team to declassify messages on the debian-private mailing list three years after posting, with a set of exceptions. The volunteers are required to contact authors and give four to eight weeks to object to messages being made public. Posts with any financial information about outside organizations would not be published, and the posts are to be available to all Debian Developers two weeks prior to publication. The developer body can overrule publication by another General Resolution, even if the author consents.
that debian-private went against the Debian Social Contract. According to Towns, the list has hosted important discussions in the evolution of Debian. The discussions should be open for examination at some point for academics and other projects to see how Debian has dealt with those issues.
Ruoso's amendment, which was approved, applied the GR only to messages sent after the GR passed. Thus, no messages prior to the end of 2005 are eligible for declassification.
In theory, the process of declassifying messages from 2006 onwards
should be well underway. In practice, the GR seems to be an unfunded
mandate. Volunteers to do the work seem to be in short supply. McIntyre
asked for volunteers in January 2009, but little
interest was shown. In May, current DPL Stefano Zacchiroli posted a request for volunteers for the declassification team to debian-project.
Since volunteer bodies seemed in short supply, Martin Krafft offered a simpler method. Krafft suggested that "archive chunks" be made available at monthly periods, with two months for authors to delete posts they don't wish disclosed. This was rejected as it does not fit with the original GR, and because some participants on debian-private in 2006 may no longer be Debian Developers — thus lacking access to delete messages.
The amount of work required may scare off the few developers actually interested in taking on the task. Don Armstrong replied to Zacchiroli's call for volunteers by saying he'd considered taking on the task and gave up:
I had actually glanced at working on this earlier, but stopped after a small bit of time, because it wasn't particularly useful, and because the sheer amount of work that it would require to satisfy the terms of the GR. (And frankly, the majority of the conversations in the archive either aren't interesting enough to bother publishing, or are on topics that such a large number of people will want their messages redacted, that it's kind of useless.)
Giacomo A. Catenazzi suggests, in a recent posting, that much of the discussion on debian-private is private because "we don't want to show all world about our vacation dates and destinations, about health and children, about personal issues we have with other people (in and outside Debian), etc." Russ Allbery echoed Armstrong, saying that many developers seem unwilling to declassify anything of interest:
The GR was an interesting idea, but based on the number of debian-private participants who, for anything that would be of any interest whatsoever after three years, have said they don't want their messages ever disclosed, I think in practice participants have spoken and have basically vetoed any sort of effective disclosure.
As it stands, it looks like the declassification GR will result in few or no messages being made public. The only action thus far is a status page reiterating the call for Debian Developers to take up the task. Zacchiroli posted an update on June 25 saying that some volunteers had been located, but "no one with actually enough free time to start doing the declassification right now."
This may be no great loss. The final GR, with the amendment constraining declassification to messages sent after January 1, 2006, means that messages showing the early evolution of Debian would not be made public. The provision that developers can veto release of messages after that date ensures that little of a controversial nature would be released, leaving little worth reading. As Andreas Tille suggests, it may be a better use of developers' time to fix RC bugs than spend time slogging through old debian-private discussions to prove just how open Debian is as a project.
One might also wonder why the project does not simply abolish debian-private altogether, in the spirit of openness. However, that would likely move sensitive discussions off of a project list altogether. It may be that the best option is discussion on a list open to all Debian Developers, but closed to the larger public, rather than discussions held out of view of the majority of the project.
Comments (18 posted)
Page editor: Jake Edge
Next page: Security>>