User: Password:
|
|
Subscribe / Log in / New account

Leading items

A line in the sand for graphics drivers

By Jonathan Corbet
July 5, 2010
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 same questions.

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 "derived work".

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 so clear.

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 classic example.

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 their suppliers.

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 pressures.

Comments (97 posted)

Trying out Firefox 4

By Jake Edge
July 7, 2010

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 announced the 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.

[Full-screen mode]

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 the top that hide themselves when they aren't needed.

[HTML5 WebM
video]

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 Firefox 3.5.10.

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 [Addons tab] 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 how getComputedStyle() works in JavaScript. That will be a 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.

[Feedback tool]

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)

Debian declassification delayed

July 6, 2010

This article was contributed by Joe 'Zonker' Brockmeier.

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.

Towns reasoned 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>>


Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds