LWN.net Weekly Edition for September 25, 2008

User manuals for free software

Documentation for free software is generally a problem area, both for users and developers. But developers at least have the code to consult, whereas most users are left poking around through menu items and consulting multiple web pages. The FLOSS Manuals project is using techniques similar to those used in free software development to produce manuals for users.

The project seeks to create the kind of manuals that users may be used to from proprietary software packages. The project's About page describes the manuals being produced:

There are a wide variety of manuals in progress, covering graphics and audio tools, OpenOffice, Firefox, WordPress for blogging, and more. The most recent addition is a set of eight manuals for the One Laptop Per Child XO. These were created as part of a XO/Sugar book sprint held in August in Austin, Texas. The manuals cover the XO hardware and Sugar interface as well as six different activities that are available as part of Sugar.

The use of a "sprint" is just part of the adoption of free software development strategies. The project is set up to allow for collaborative development by a community. FLOSS Manuals describes it this way:

The manuals themselves are available in a variety of formats: HTML, PDF, as well as dead tree. One of the more interesting features is the remix capability. Using an AJAX interface, one can pick and choose from the chapters of existing manuals to create a custom manual that includes only the pieces required for some group of users. Remixers can choose their own cover and title, then export it all as a PDF file. Instead, one can also cut and paste some javascript code into a web page that creates a reader application on the page. In this way, the custom manual will always be up-to-date with the latest changes made to the chapters.

FLOSS manuals clearly fill a niche that is needed in the free software world. The manuals have a rather professional look that will immediately stand out to users. There is a lot of work to be done, but it would appear that the project has made an excellent start. As one might guess, it is always looking for more interested folks to write, edit, and proofread manuals.

(Thanks to LWN reader David Farning for suggesting we look at this project.)

Comments (13 posted)

LPC: Booting Linux in five seconds

At the Linux Plumbers Conference Thursday, Arjan van de Ven, Linux developer at Intel and author of PowerTOP, and Auke Kok, another Linux developer at Intel's Open Source Technology Center, demonstrated a Linux system booting in five seconds. The hardware was an Asus EEE PC, which has solid-state storage, and the two developers beat the five second mark with two software loads: one modified Fedora and one modified Moblin. They had to hold up the EEE PC for the audience, since the time required to finish booting was less than the time needed for the projector to sync.

How did they do it? Arjan said it starts with the right attitude. "It's not about booting faster, it's about booting in 5 seconds." Instead of saving a second here and there, set a time budget for the whole system, and make each step of the boot finish in its allotted time. And no cheating. "Done booting means CPU and disk idle," Arjan said. No fair putting up the desktop while still starting services behind the scenes. (An audience member pointed out that Microsoft does this.) The "done booting" time did not include bringing up the network, but did include starting NetworkManager. A system with a conventional hard disk will have to take longer to start up: Arjan said he has run the same load on a ThinkPad and achieved a 10-second boot time.

Out of the box, Fedora takes 45 seconds from power on to GDM login screen. A tool called Bootchart, by Ziga Mahkovec, offers some details. In a Bootchart graph of the Fedora boot (fig. 1), the system does some apparently time-wasting things. It spends a full second starting the loopback device—checking to see if all the network interfaces on the system are loopback. Then there's two seconds to start "sendmail." "Everybody pays because someone else wants to run a mail server," Arjan said, and suggested that for the common laptop use case—an SMTP server used only for outgoing mail—the user can simply run ssmtp.

Figure 1

Another time-consuming process on Fedora was "setroubleshootd," a useful tool for finding problems with Security Enhanced Linux (SELinux) configuration. It took five seconds. Fedora was not to blame for everything. Some upstream projects had puzzling delays as well. The X Window System runs the C preprocessor and compiler on startup, in order to build its keyboard mappings.

Ubuntu's boot time is about the same: two seconds shorter (fig. 2). It spends 12 seconds running modprobe running a shell running modprobe, which ends up loading a single module. The tool for adding license-restricted drivers takes 2.5 seconds—on a system with no restricted drivers needed. "Everybody else pays for the binary driver," Arjan said. And Ubuntu's GDM takes another 2.5 seconds of pure CPU time, to display the background image.

Figure 2

Both distributions use splash screens. Arjan and Auke agreed, "We hate splash screens. By the time you see it, we want to be done." The development time that distributions spend on splash screens is much more than the Intel team spent on booting fast enough not to need one.

How they did it: the kernel

Step one was to make the budget. The kernel gets one second to start, including all modules. "Early boot" including init scripts and background tasks, gets another second. X gets another second, and the desktop environment gets two.

The kernel has to be built without initrd, which takes half a second with nothing in it. So all modules required for boot must be built into the kernel. "With a handful of modules you cover 95% of laptops out there," Arjan said. He suggested building an initrd-based image to cover the remaining 5%.

Some kernel work made it possible to do asynchronous initialization of some subsystems. For example, the modified kernel starts the Advanced Host Controller Interface (AHCI) initialization, to handle storage, at the same time as the Universal Host Controller Interface (UHCI), in order to handle USB (fig.3). "We can boot the kernel probably in half a second but we got it down to a second and we stopped," Arjan said. The kernel should be down to half a second by 2.6.28, thanks to a brand-new fix in the AHCI support, he added.

Figure 3

One more kernel change was a small patch to support readahead. The kernel now keeps track of which blocks it has to read at boot, then makes that information available to userspace when booting is complete. That enables readahead, which is part of the early boot process.

How they did it: readahead and init

Fedora uses Upstart as a replacement for the historic "init" that traditionally is the first userspace program to run. But the Intel team went back to the original init. The order of tasks that init handles is modified to do three things at the same time: first, an "sReadahead" process, to read blocks from disk so that they're cached in memory, second, the critical path: filesystem check, then the D-Bus inter-process communication system, then X, then the desktop. And the third set of programs to start is the Hardware Abstraction Layer (HAL), then the udev manager for hot-plugged devices, then networking. udev is used only to support devices that might be added later—the system has a persistent, old-school /dev directory so that boot doesn't depend on udev.

The arrangement of tasks helps get efficient use out of the CPU. For example, X delays for about half a second probing for video modes, and that's when HAL does its CPU-intensive startup (fig. 4).

Figure 4

In a graph of disk and CPU use, both are at maximum for most of the boot time, thanks to sReadahead. When X starts, it never has to wait to read from disk, since everything it needs is already in cache. sReadahead is based on Fedora Readahead, but is modified to take advantage of the kernel's new list of blocks read. sReadahead is to be released next week on moblin.org, and the kernel patch is intended for mainline as soon as Arjan can go over it with ext3 filesystem maintainer Ted Ts'o. (Ted, in the audience, offered some suggestions for reordering blocks on disk to speed boot even further.)

There's a hard limit of 75MB of reads in order to boot, set by the maximum transfer speed of the Flash storage: 3 seconds of I/O at 25MB/s. So, "We don't read the whole file. We read only the pieces of the file we actually use," Arjan said. sReadahead uses the "idle" I/O scheduler, so that if anything else needs the disk it gets it. With readahead turned off, the system boots in seven seconds, but with readahead, it meets the target of five.

X is still problematic. "We had to do a lot of damage to X," Arjan said. Some of the work involved eliminating the C compiler run by re-using keyboard mappings, but other work was more temporary. The current line of X development, though, puts more of the hardware detection and configuration into the kernel, which should cut the total startup time. Since part of the kernel's time budget is already spent waiting for hardware to initialize, and it can initialize more than one thing at a time, it's a more efficient use of time to have the kernel initialize the video hardware at the same time it does USB and ATA. X developer Keith Packard, in the audience and also an Intel employee, offered help. Setting the video mode in the kernel would not let the kernel initialize it at the same time as the rest of the hardware, as shown in figure 3. The fast-booting system does not use GDM but boots straight to a user session, running the XFCE desktop environment. Instead of GDM, Arjan said later, a distribution could boot to the desktop session of the last user, but start the screensaver right away. If a different user wanted to log in, he or she could use the screensaver's "switch user" button.

Figure 5

In conclusion, Arjan said, "Don't settle for 'make boot faster.' It's the wrong question. The question is 'make boot fast'." And don't make all users wait because a few people run a filesystem that requires a module or sendmail on their laptops. "Make it so you only pay the price if you use the feature." Distributions shouldn't have to maintain separate initrd-based and initrd-free kernel packages, he said later. The kernel could try to boot initrd-free, then fall back if for whatever reason it couldn't see /sbin/init, as might happen if it's missing the module needed to mount the root filesystem.

PowerTOP spawned a flurry of power-saving hacks from all areas of the Linux software scene. The combination of Bootchart, readahead, and a five-second target looks likely to set off a friendly boot time contest among Linux people as well. At the conference roundup Friday, speaker Kyle McMartin announced that both Fedora and Ubuntu have fixed some delays in their boot process, and there was much applause.

Comments (166 posted)

The Linux Plumbers Conference: a summary

There is a certain appeal to overseas events, but that appeal fades more quickly than one might expect. The need for long-haul travel also excludes US-based developers who are unable to arrange funding. So, for some years, the development community in the US has been wishing for a local conference. More recently, a dedicated group of Portland-based developers led by Kristen Carlson Accardi, with some help from the Linux Foundation, decided to do something about it. The result was the first edition of the Linux Plumbers Conference, held September 17 to 19. Staging this conference in a world which does not lack for conferences was a bit of a risk, and the organizers added a few risks of their own to the mix. Looking back, your editor can say that those risks were well repaid; the first Linux Plumbers Conference was a great success.

The "plumbing" focus of this event was well chosen. While it is still possible to run a system with a bare kernel and a shell as the init process, Linux systems used for real work increasingly have a layer of user-space software tightly wrapped around the kernel. Quite a bit of kernel-based functionality only works properly in the presence of a tightly-coupled user-space component; examples include system initialization, 3D graphics, and much more. The kernel, along with its collection of user-space software, makes up the "plumbing" layer which makes everything else work. Kernel developers have had ample opportunities to get together in recent years, but there has been no concerted effort to bring together the developers for the full plumbing layer until now.

The other significant change made by the LPC organizers was to do away with the "everybody delivers a paper" format used by most conferences. Instead, the conference was planned as a series of 2.5-hour "microconferences," each with a specific focus. Each microconference, which had its own "runner," was able to select its own mode of operation. They generally included a certain number of presentations on relevant topics; in this sense, the microconferences resemble the topic-specific tracks found at many academic gatherings.

Where things differ, though, is that most of the microconferences were explicitly oriented toward discussion and problem solving. The best speakers did not (just) talk about their own project; they raised challenges for the group as a whole to address. It worked spectacularly well. Throughout the event, your editor saw rooms full of people who were fully engaged in the work at hand. The discussions had wide participation, most of the necessary people were generally in the room, and there were relatively few bored people checking email. And, most importantly, a lot of real work got done. Developers came out of the sessions with a clear idea of what needs to be done, agreement with others on how it was to be done, and, sometimes, working code.

So, what did all of these developers talk about?

• Developers interested in storage talked about the iogrind tool and a number of outstanding problems; some notes from the session have been posted.

• The Audio microconference covered a wide range of issues; see this LWN article for a summary.

• A session on tracing saw presentations by developers of a number of competing technologies, followed by a focused effort to design a unified low-level shared relay buffer.

• The video input session, for all practical purposes, continued on and off through the entire conference; that group of developers, which had never met before, set in motion some major redesign efforts for the Video4Linux layer.

• The bootstrap and initialization session was dominated by Arjan van de Ven's five-second boot demonstration; having been given that challenge, developers from multiple distributions set about the task of getting their systems to boot quickly.

• A session on server management looked for solutions to a number of challenges facing Linux administrators.

• Kernel/user-space APIs were the topic of another lively session which, while perhaps concluding little, raised a lot of issues on how those APIs should be designed.

• The power management session concluded that the suspend/resume problem is solved ("if you disagree, you bought the wrong hardware") and made progress on a number of other problems; now, they say, all that is left is the coding.

• The "future displays" session pounded out the path toward kernel-based graphics mode setting and quite a bit more.

• And the desktop integration session, while reaching "not a lot of conclusions," examined a number of relevant issues; the discussion on Upstart from that session will be covered here separately.

Beyond that, LPC attendees could choose from a handful of more traditional presentations, a provocative keynote from Greg Kroah-Hartman, a rather less provocative kernel update from your editor, a git tutorial taught by some guy named Linus, and no shortage of evening celebrations. All told, the Linux Plumbers Conference was one of the most productive, interesting, and generally worthwhile events your editor has been to in quite some time - and your editor has been to rather more than the usual number of events. There will be a lot of interesting developments kicked off by this gathering, once the exhausted attendees get some rest. This conference is off to a good start.

And it is just a start; the organizers are already working on the 2009 edition. It will, once again, be held in Portland. The general format will likely remain the same, but there will be no kernel summit before the 2009 event (the summit will be in October 2009 in Tokyo). Instead, there is a reasonable chance that a more traditional, presentation-oriented conference will be planned to coincide with the 2009 Plumbers Conference. With this new event, the active local community, and the success of this year's conference, LPC2009 looks promising already.

After 2009, the Plumbers team hopes to take a page from the linux.conf.au playbook and pass the event onto a new set of volunteer organizers somewhere else in North America. This form of organization has helped to keep linux.conf.au vital and interesting for many years; it makes sense to do something similar with the Linux Plumbers Conference. Now might be a good time for any North American community which would like to host this event in 2010 to start thinking about how it could be done.

Comments (18 posted)

Leo Laporte on open micro-blogging

Radio talk show and podcast host Leo Laporte doesn't think operating systems or network infrastructures should ever be proprietary. He's the host of The Tech Guy radio show, which airs every weekend on stations around the United States, and of FLOSS Weekly, a regular podcast in which Laporte discusses different aspects of the Free, Libre, and Open Source software community. On The Tech Guy show, Laporte answers questions from computer users who call in to get advice and find ways to make their computers run better. Most of his callers are Windows users, but Laporte usually finds a way to mention Linux and other open source software during the course of his show.

Laporte says he has been writing software for decades, and that he has always shared the source code, even before he had a notion of open source. "It was public domain then. But even then, I understood that if you're programming, the most interesting part is to see other people's code and be able to modify it. That's just a natural way to work." His first shot at installing Linux was back in 1994 when he got his hands on a copy of Slackware. "It was murder — but it opened my eyes to the growing open source world."

At the time, Laporte was the host of a cable television show called Tech TV. "We were the first television show to install Linux live." On that show, Laporte hosted some of the biggest names in FLOSS, including Linus Torvalds and Richard Stallman, during Tech TV's run. "The longer I worked as a computer journalist, the more obvious it became to me that proprietary software is a bad idea. It's not natural to be secretive and it doesn't make sense." Laporte says that especially in the enterprise, the technological infrastructure should be open. "That should never be proprietary. Protocols, standards, and code need to be open."

When it comes to applications, Laporte is a bit more flexible. "If you want to write an app that is closed source, I can see there are reasons why one might want to do that and that's fine with me. But closing the operating system makes no sense, and it is bad for everybody."

Laporte, a Twitter user with over fifty-five thousand followers, recently announced he would no longer use Twitter, but would instead now throw his support behind Laconica, the open source micro-blogging platform on which Identi.ca is built. Laporte spoke extensively about Laconica on FLOSS Weekly last month when he chatted with Evan Prodromou, the original author of Laconica and the person who maintains identi.ca.

"Laconica is identical to Twitter, but it's open, which is huge, and, more than open just in terms of it being open source." Laporte says open standards are just as important in this case, and that the protocols for micro-blogging should become commoditized so that others can build on top of the infrastructure instead of having to start from scratch. Laconica also offers users the option to release all their micro-posts under a Creative Commons attribution license, making the service about as "open as you could hope for," writes Dan Brickley, co-founder of the Friend of a Friend project (FOAF).

With Laconica, different micro-blogging services can communicate with each other since the platform is open, unlike Twitter's service. This makes it possible for different communities to form their own branded services in which users can still search for and follow users in other communities, tying them together in what has become known as a "federation." Right now, Laconica is running on dozens of disparate servers, whose users can all subscribe to each others' updates. Laconica is built using the OpenMicroBlogging specification, which is completely open, free, and independent of any one central maintenance authority, unlike Twitter's proprietary protocol.

Laporte believes that this kind of federation, which could be called distributed micro-blogging, is the key to overcoming scalability issues that have plagued Twitter, resulting in frequent outages for the popular service. "If you can't scale, that's another reason to have a more distributed system. Maybe we shouldn't have two million people on one Twitter. Maybe we should have five thousand people on four hundred 'twitters.' I have three thousand people on my system, and that's just about right."

Laporte's system is called the TWiT Army, [Note that the web site is currently down] named after another of his podcasts known as This Week in Tech, or TWiT. "The conversation [there] has been very cohesive. The conversation is with people you know. With Twitter, it turns into a broadcast medium instead of a conversation. Now, it is a very useful way to get a message out to all those people. But I would love to have all those people all in their own communities, able to search across the federation by keyword, and if I post something of interest they'll find out about it."

Laporte says he is not trying to go "head to head" against Twitter. But he is convinced that Laconica is a better way to do micro-blogging. "One of my problems with Twitter is that I contribute a lot of content and they shut down access to it. I want to be part of an open platform — that's where the innovation is going to occur."

Laporte says that features Twitter previously offered but has shut down, including instant messaging and "track," are two of the most valuable features that Twitter offered. "Comcast realized a huge value from Track," he says. Comcast customer service agents were tracking Twitter posts to monitor complaints or issues posted by users, and then following up directly with those people. "Twitter was saying, 'well it's too demanding,' but the conspiracy theory is that they realize this is where the real value of Twitter is and they want to try to monetize it." With Laconica, Laporte says, these types of features can remain open and accessible, not subject to the whims of proprietary ownership.

Laporte, Prodromou, and others including RSS pioneer Dave Winer, are talking about a collaborative effort to standardize and open the protocols for micro-blogging. The group is planning a conference for all who are interested in the concept of open micro-blogging, called the BearhugCamp. Laporte says, "we would very much like to encourage Twitter to become a part. The idea is to get all the players to the table and encourage them to support the Extensible Messaging and Presence Protocol (XMPP) (developed by Jabber). We're creating a new messaging medium with emerging open standards, in new and exciting ways. It's not really about Twitter at all – Twitter gave us this idea of micro-blogging, and now we're onto the next thing: let's make it open."

Comments (1 posted)

Page editor: Jonathan Corbet

Security

Mobile phone or penetration tool?

The NeoPwn is a pocket-sized network penetration tool based on Linux and free software. The form factor should be familiar to anyone that has paid attention to the Linux mobile phone market as NeoPwn is based on the OpenMoko Neo FreeRunner. When the device starts shipping, users will be able to do network monitoring and penetration testing from an unobtrusive platform—then call home with it.

NeoPwn comes with an impressive array of free software security tools, including things like Metasploit, Aircrack-ng, WifiZoo, Wireshark, and many others. They all run on top of a customized Linux 2.6.24 kernel—sources to be released when the hardware ships, which is scheduled for October 1—from the microSD flash module. A full Debian distribution is included on a flash filesystem that has been optimized for performance and size.

The company behind NeoPwn has also created a GUI interface to the system for hardware control as well as attack automation. The interface is meant to reduce the need for using the command line for the most common types of attacks. Using the tools, Wired Equivalent Privacy (WEP) keys can be cracked in 5 to 14 minutes depending on whether the network has clients connected or not. The NeoPwn is not set up to crack Wifi Protected Access (WPA) keys on the device itself, but it can capture the handshake for use by programs on more powerful systems.

There are several different options for purchasing the NeoPwn—all of them rather pricey. The basic model is $699 for the phone (normally $399), software, and some useful accessories. One can also just purchase the software on a 2GB microSD card for $79. The website has a prominent warning that might deter some, however: "Please be advised that if you do not choose a complete system, you will have to program the phone's bootloader manually for the correct microSD bootloader entry, to the NAND memory. This can be dangerous if you do not know what you are doing!"

The standard FreeRunner Wifi has firmware limitations that will not allow monitoring or packet injection—pretty important capabilities for a network security tool—so various USB Wifi cards come with the NeoPwn. Also, since a custom kernel is used, one cannot make phone calls and do penetration testing at the same time. At boot time, one must choose between the two modes. Even with those limitations, the FreeRunner seems like an excellent choice as a platform.

For those puzzled by the name, "pwn" is used for the word "own" in the "leetspeak" used by many in the security community—both white and black hat. Breaking into and controlling a network or system is then "pwning" it. NeoPwn is not alone in using the term. Metasploit author H D Moore's iPwn Mobile makes UMPC-based penetration testing devices.

Both the NeoPwn and iPwn Mobile's Infiltrator look like useful devices for those needing an off-the-shelf solution, but because they are based on free software, the core capabilities are available to those with a lower budget. By showing what can be done with open mobile phones like the FreeRunner, NeoPwn is doing a great service for both OpenMoko and the free software community. Undoubtedly various malicious folks will get their hands on devices like this, so it is important that security researchers and professionals have access to them as well.

Comments (1 posted)

New vulnerabilities

ed: heap-based buffer overflow

Comments (3 posted)

firefox: multiple vulnerabilities

Comments (none posted)

havp: denial of service

Comments (none posted)

horde3: cross-site scripting

Comments (none posted)

mantis: multiple vulnerabilities

Comments (none posted)

mercurial: remote information exposure

Comments (none posted)

newsbeuter: execution of arbitrary code

Comments (none posted)

phpmyadmin: multiple vulnerabilities

Comments (none posted)

twiki: arbitrary code execution

Comments (none posted)

Page editor: Jake Edge

Kernel development

Release status

Kernel release status

Several dozen fixes have been merged into the mainline git repository since the 2.6.27-rc7 release.

The linux-next tree has abruptly taken a break; it is expected to return around October 13.

Comments (none posted)

Kernel development news

Quotes of the week

-	early_printk("Kernel really alive\n");
+	early_printk("Kernel really alive! It's alive! IT'S ALIIIIIIIIIVE!\n");

Comments (1 posted)

e1000e and the joy of development kernels

As of this writing, though, nobody seems to know what the problem is. There was some confusion resulting from the fact that the related e1000 driver also suffered from an EEPROM corruption problem - but that turns out to have been an entirely different bug. The e1000 problem was fixed by putting a lock around accesses to the EEPROM, preventing corruption caused by concurrent access. But something else is going on with the e1000e.

Figuring out what that "something else" is appears to be a challenge. The problem is not readily reproducible, and there is this little problem that triggering the bug more than once requires the replacement of the affected hardware. It's not even clear which kernel versions are affected, though it appears that only the 2.6.27 development series shows the bug. There is some correlation between e1000e corruptions and graphics driver crashes, leading David Miller to pursue a hypothesis that the real culprit is changes to the X server, but that idea has not, yet been proven. Other developers suspect a concurrency-related problem similar to the e1000 bug.

As of this writing, the bulk of what is known can be found in this advisory from Mandriva. Kernel developers are adding information to the kernel bugzilla entry as they find it.

It has been suggested that anybody running 2.6.27 on a potentially affected system might want to save a copy of the current EEPROM contents with a command like:

    ethtool -e eth0 > eth0.eeprom

(That assumes, of course, that the relevant device is eth0 on your system). With the saved data, it should be possible to recover the device if the worst happens; without, chances are that victims will have to return their systems to the vendor.

In one sense, this bug demonstrates that the system works. It was caught while the kernel was still in the stabilization phase; one can be certain that it will be obliterated somehow before any stable 2.6.27 release comes out. On the other hand, the first report of this problem hit the net on August 8; the problem was known for over a month before distributors started responding to it and the all-out hunt for the cause began. That is a long time for any regression to persist, but it is especially long when one is dealing with a regression which has the ability to regress hardware back to a stone-age state.

The distributors have now responded; most of them have withdrawn kernels with the affected drivers. So far, nobody has posted tools to help affected users recover their hardware (suggestions to use ibautil should be ignored and forgotten about as soon as possible). Such a tool is forthcoming, but it would be hard to blame the relevant engineers for focusing on fixing the problem first. With any luck at all, the root cause will have been isolated by the time you read this.

There is one thing that will not have changed, though. Testers of unstable software - especially the kernel - have often been warned that said software can do all kinds of terrible things to their systems. It is easy to ignore those warnings; even -rc1 kernels actually work for most people, most of the time. But, as we have seen in this case, the potential for catastrophic bugs is real. Development code can brick your network adapter, scramble your filesystems, open up severe security holes, or save your documents as OOXML. When experimenting with unstable code - even if it has been neatly packaged by your distributor - it is always prudent to have good backups and an even better sense of humor.

Comments (14 posted)

LPC: The future of Linux graphics

There are two major components to the work which is being done: graphics memory management and kernel-based mode setting. A contemporary graphics processor (GPU) is really a CPU in all respects, including the possession of a sophisticated memory management unit. Managing the sharing of memory between user space, the kernel, and the GPU is fundamental to the implementation of correct, high-performance graphics. One year ago, the TTM subsystem looked like the solution to the memory management problem, but TTM grew increasingly unworkable as the understanding of the problem improved. So now the Graphics Execution Manager (GEM) code looks like the way forward; it is currently being prepared for merging into the mainline kernel.

Kernel-based mode setting, instead, is meant to get user-space code out of the business of messing around directly with the hardware. Putting the kernel in charge of the configuration of the video adapter has a long list of advantages. Suspend and resume have a much better chance of working, for example. Once the X server stops accessing hardware directly, it no longer needs to run as root; having that much untrusted code running with full privileges has made people nervous for many years. In the current scheme, the kernel cannot change the graphics mode if it needs to; that means that, for example, if the system panics, a graphical user will never see the message. With kernel-based mode setting, the kernel can switch to a different mode and allow the user to frantically try to read the message before it scrolls off the screen. Kernel-based mode setting will also make fast user switching work much better, without the need to use a separate virtual terminal for each user session.

One of the first topics of discussion was: how does the kernel decide when to switch to the panic screen to show the user an important message? There are quite a few different paths by which the kernel can indicate distress; should a kernel message be presented every time a WARN_ON() condition is encountered? There would appear to be a need to unify the error paths in the kernel to help simplify this kind of decision. Linus Torvalds Jesse Barnes suggested that the kernel could simply switch on every message emitted with printk(), on the theory that such a policy would lead to a rapid and welcome reduction in kernel verbosity.

The real debate in this session, though, had to do with development process. As has been discussed previously on LWN, much of the video driver work is done outside of the mainline kernel tree. We are now seeing a big chunk of that work being prepared for a merge. But the new mode setting interface is a big API change which will require adjustments from user space; a new kernel expecting to handle mode setting may not give the best results when run with an older user space X server. So there will be a big flag day of sorts when everything changes and all of the new code gets run for the first time.

Linus is not pleased with the notion of a video graphics flag day; he made a long appeal for a more incremental approach to fixing the video driver work. In his opinion, the flag day will lead to a whole bunch of untested code being made active all at once; there will certainly be design mistakes which show up, and the whole thing will fail to work properly. At which point another flag day will be required. Linus was not impressed by the claim that Fedora users have selflessly been testing this code for everybody; in his view, the kernel developers are not doing this testing. He sees the whole thing as a recipe for disaster.

The real problem - and the reason for the out-of-tree development - is that all of this work requires the creation of a number of new, complex user-space ABIs. That is true for both mode setting and memory management, and the two cannot be easily separated from each other. Until the combination as a whole is seen to work, the video driver developers simply cannot commit themselves to a stable user-space interface - and that means that their code cannot be merged.

As an example, TTM was cited. Had that code been pushed when it looked like the right solution, there would now be even bigger problems to solve.

In summary, the graphics developers believe that the approach they are taking is as incremental as they can make it. Whether they convinced Linus of that fact is unclear, but he eventually seemed to accept the plan. He did ask for them to push the mode setting code upstream first, but that code cannot work without memory management support. So GEM will go into the mainline ahead of kernel-based mode setting. Once everything is in the kernel, it will be possible to boot a system with either kernel-based or user-space mode setting, so both new and old distributions will be supported. Someday, in the distant future, support for mode setting in user space can be removed. Much sooner than that, though, we should all be running much-improved graphics code and will have long since forgotten how things used to be.

Comments (10 posted)

Newer kernels and older SELinux policies

A subtle change in 2.6.25 recently left Andrew Morton with a less than completely functioning system, but it also demonstrated a user-space interface that may sometimes be overlooked: SELinux. The problem stemmed from a change to facilitate containers by making /proc/net into a symbolic link, which tripped up SELinux policies that had been written for earlier kernels. Putting policy into user space is a guiding principle of kernel development, but that can sometimes lead to an unexpected synchronization required between those policies and the kernel.

The change itself was fairly minor, making /proc/net be a symbolic link to /proc/self/net so that containers would only see their network devices, rather than those of the enclosing system. But when Morton ran a recent kernel on his Fedora Core 5 and 6 systems, he got:

    sony:/home/akpm> ifconfig -a
    Warning: cannot open /proc/net/dev (Permission denied). Limited output.

When the change was made, back in March, it was reviewed by the SELinux developers, but no one noticed that it would cause an additional permission check—on the symbolic link itself. So, when resolving things like /proc/net/dev or other entries in that directory, the "labels" on the symbolic link were checked. Of course, /proc is a synthetic filesystem, so the labels are generated from SELinux code rather than retrieved from extended attributes (xattrs).

Distributions have updated their policies to allow access to the symbolic link—probably by noticing the SELinux denial in log messages—so most folks never saw the problem. As Morton found out, though, existing distribution policy files (those shipped with FC5 and FC6 for example) would still disallow the access. Morton regularly runs newer kernels with older distributions to try to catch exactly this kind of error; he is probably one of very few, perhaps the only one, doing that.

Because the distribution-supplied kernel was being changed, some argued that requiring users to update their SELinux policies is not an onerous requirement. Paul Moore puts it this way:

Morton did not buy that argument saying:

But SELinux developer Stephen Smalley points out that permissions checks are not normally considered part of the kernel to user space interface. It is something of a gray area, though. Clearly the standard UNIX permission checks are part of that interface, at least partially because the kernel does handle the policy for those checks. Since the policies that govern the decisions about SELinux access denial come from user space, it is a bit hard to argue that changes to the kernel will not ripple out. Smalley describes the problem:

One possible solution to the immediate problem was floated by Smalley: SELinux could change the label that it returns for symbolic links under /proc. It is not clear that anyone really wants that change, and there has been no movement to add it. As Morton says, "people who are shipping 2.6.25- and 2.6.26-based distros probably wouldn't want such a patch in their kernels anyway."

Longer term, Eric Biederman asks about supporting xattrs for /proc. That would allow user space to label the proc filesystem appropriately, removing one of the special cases. Unfortunately, doing so would create yet another incompatibility between newer kernels and older user spaces.

In the end, because the bug was only seen by Morton, many months after it was introduced, it may just be ignored. The larger issue of how permissions checks fit into the kernel to user space interface, though, may rear its head again.

Comments (4 posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 2.6.27-rc7. (September 21, 2008)

Core kernel code

• Lai Jiangshan: rcu: introduce kfree_rcu(). (September 18, 2008)

• Arjan van de Ven: What's in hrtimer.git for 2.6.28. (September 21, 2008)

• Arjan van de Ven: What's in fastboot.git for 2.6.28. (September 21, 2008)

• Krishna Kumar: workqueue: Two API's to update delayed works quickly. (September 22, 2008)

• Paul E. McKenney: v6 scalable classic RCU implementation. (September 24, 2008)

• Vaidyanathan Srinivasan: Modular find_busiest_group(). (September 24, 2008)

Development tools

• Martin Bligh: Unified tracing buffer. (September 21, 2008)

• Steven Rostedt: An Unified tracing buffer (attempt). (September 24, 2008)

• Arjan van de Ven: debug: Introduce a dev_WARN() function. (September 21, 2008)

• Arjan van de Ven: Whats in kerneloops.git for 2.6.28. (September 21, 2008)

• Steven Noonan: ftrace: add nop tracer. (September 22, 2008)

Device drivers

• Christian Pellegrin: max3100 driver. (September 21, 2008)

• Kalle Valo: stlc45xx: open source WLAN driver for N800 and N810. (September 22, 2008)

• Elias Oltmanns: Disk shock protection in GNU/Linux. (September 22, 2008)

• Guo-Fu Tseng: jme: JMicron Gigabit Ethernet Driver. (September 22, 2008)

• Igor M. Liplianin: [PATCH] Add support for SDMC DM1105 PCI chip. (September 22, 2008)

• =?ISO-8859-1?Q?S=F8ren_Hauberg?=: usbtouchscreen, 2.6.25. (September 23, 2008)

• Alex Chiang: PCI: let the core manage slot names. (September 23, 2008)

Documentation

• Michael Kerrisk: man-pages-3.10 is released. (September 24, 2008)

Filesystems and block I/O

• Josef 'Jeff' Sipek: CMS minidisk filesystem support. (September 22, 2008)

• Daniel Phillips: Tux3 kernel port, latest snapshot. (September 22, 2008)

• Theodore Ts'o: ext4: Use preallocation when reading from the inode table. (September 23, 2008)

• Jens Axboe: What's in in the block git tree for 2.6.28?. (September 24, 2008)

• Ryo Tsuruta: I/O bandwidth controller and BIO tracking. (September 24, 2008)

• Evgeniy Polyakov: Distributed storage maintenance release.. (September 24, 2008)

Memory management

• Christoph Lameter: Cpu alloc V5: Replace percpu allocator in modules.c. (September 22, 2008)

• Nick Piggin: mm: pageable memory allocator (for DRM-GEM?). (September 23, 2008)

• Mel Gorman: Report the size of pages backing VMAs in /proc V2. (September 24, 2008)

Networking

• =?iso-8859-1?q?R=E9mi?= Denis-Courmont: PhoNet protocols stack v2. (September 22, 2008)

• Johannes Berg: technology preview: scan with cfg80211. (September 22, 2008)

Architecture-specific

• Joerg Roedel: AMD IOMMU 2.6.28 updates for review. (September 22, 2008)

• Joerg Roedel: stackable dma_ops for x86. (September 22, 2008)

Security-related

• Serge E. Hallyn: file capabilities: add no_file_caps switch (v3). (September 24, 2008)

• Kentaro Takeda: TOMOYO Linux. (September 24, 2008)

Virtualization and containers

• Balbir Singh: Remove cgroup member from struct page (v3). (September 18, 2008)

• Ryo Tsuruta: bio-cgroup: Introduction. (September 22, 2008)

• KAMEZAWA Hiroyuki: memory cgroup updates v4. (September 22, 2008)

• Avi Kivity: KVM Updates for 2.6.28 merge window (part 1 of 3). (September 23, 2008)

Benchmarks and bugs

• Rafael J. Wysocki: 2.6.27-rc6-git6: Reported regressions from 2.6.26. (September 21, 2008)

Miscellaneous

• David Miller: patchwork for netdev. (September 22, 2008)

• Kay Sievers: udev 128 release. (September 22, 2008)

• Hans de Goede: libv4l release: 0.5.0. (September 23, 2008)

• Jesse Barnes: Notes from LPC PCI/MSI BoF session. (September 23, 2008)

Page editor: Jonathan Corbet

Distributions

News and Editorials

LPC: Upstart 1.0 plans: manifesto for a new init

Let's make two things clear about Upstart, a proposed replacement for the Linux "init" process. First, it's not there to speed up boot, and second, it's not intended to parallelize startup. "Upstart is not for what most people think it is for," said its author, Scott James Remnant, in a talk in the dbus miniconference at the Linux Plumbers Conference. What it is there for is to expand the capabilities of "init" on Linux, replace some scripts and workarounds with rules that are intended to be easier to understand and modify, and enable future improvements. Remnant is a Canonical employee, and Upstart is in Fedora as of version 9, making it a welcome example of a Canonical-sponsored project finding its way into other distributions.

While Greg Kroah-Hartman mentioned a list of core software on the Linux platform in his Plumbers Conference talk, "the one thing he never put in there was init," Remnant said. The Linux init, originally by Miquel van Smoorenburg, has been unchanged for years, and is modeled on the System V Unix init, which is even older. Instead of updating it, Remnant says that, for too long, distributions have just worked around it. The startup process has traditionally consisted of shell scripts, started by init, but containing workarounds and extensions accumulated over the years. For example, Debian has a wrapper program called start-stop-daemon, that manages PID files, to keep track of what process ID a daemon process ends up with. Upstart handles that itself.

Current features of upstart include sending notifications for system events, for example, when a service starts; eliminating race conditions, by offering dependency tracking; and removing some service startups from the critical path for boot, again by handling dependencies. Upstart allows a distribution or sysadmin to spell out the critical path in a script, and also specify dependencies. Tracking dependencies allows distributions to eliminate "sleep" loops from the boot sequence, and instead take actions based on events.

Events are not limited to the runlevel changes familiar to sysvinit users, but can depend on other things on the system. But what other things? Future directions for Upstart could be ambitious. For 1.0, Remnant is considering adding the ability to do tasks based on cron-like criteria such as "hourly." But should upstart really replace cron? Another possibly useful direction would be an "idle" event. The Common Unix Printing System (CUPS) is a service that makes sense to start "30 seconds before the user thinks of clicking on the print button," he said. CUPS is not in the critical path for boot, but needs to be running to detect printers before the user needs them. Should it be possible to start non-critical services when the system becomes idle?

Even though fast boot isn't the goal of upstart, Remnant is optimistic about being able to help. Some of the slow booting problems that Arjan van de Ven and Auke Kok identified at the conference are deep in the weeds of nested scripts, and might be smoked out by a simpler init layout. "To make boot fast we have to do a bunch of different stuff. it makes it easy for us to do the real work," Remnant said.

Comments (8 posted)

New Releases

Information on the e1000e corruption bug

Comments (13 posted)

Introducing Foresight Kids Edition

Full Story (comments: none)

openSUSE 11.1 Beta 1 now available

Update: See this warning before installing on a system with an Intel e1000e network card.

Full Story (comments: 1)

Orange Sombrero 9 Released - based on Fedora

Full Story (comments: 7)

Intrepid Alpha 6 released

Full Story (comments: none)

Distribution News

Fedora

Fedora 10 likely to slip again

Full Story (comments: none)

Fedora intrusion update

Full Story (comments: 12)

Fedora Board Recap 2008-SEP-16

Full Story (comments: none)

Mandriva Linux

Mandriva announces a new solution for netbooks: Mandriva Mini

Comments (none posted)

SUSE Linux and openSUSE

openSUSE Build Service did it!

Full Story (comments: none)

Serious e1000e Driver Issue in SLE 11 Beta 1 and openSUSE 11.1 Beta 1

Full Story (comments: 9)

Ubuntu family

Serious, potentially hardware-damaging e1000e driver issue on Intrepid

Full Story (comments: none)

Distribution Newsletters

Ubuntu Weekly Newsletter #109

Full Story (comments: none)

OpenSUSE Weekly News/39

Comments (none posted)

Fedora Weekly News #144

Full Story (comments: none)

DistroWatch Weekly, Issue 271

Comments (none posted)

Distribution meetings

FUDCon Brno 2008 (Red Hat Magazine)

Comments (none posted)

Distribution reviews

ASUS Eee PC 901 / Intel Atom: Linux Distribution Comparison (Phoronix)

Comments (5 posted)

Page editor: Rebecca Sobol

Development

LPC: Linux audio: it's a mess

Audio is a fitting topic for the first day of the Linux Plumbers Conference. Users want sound to Just Work, and there's lots of working code in individual projects. But so far, it seems like nobody has everything quite plumbed together in an annoyance-free way.

Lennart Poettering, a lead developer of PulseAudio and Red Hat employee, moderated the miniconference and started with a summary of the state of Linux audio: "it's a mess." The audio miniconference came up with two steps toward cleaning up the mess, though. First, come up with a coherent story for application developers on what sound API to use, and how. Second, clean up the often-confusing array of user-visible audio level controls.

PulseAudio first appeared to regular users in Fedora, starting with version 8, and now, as Lennart puts it, is for up-to-date users, "the software that currently breaks your audio." PulseAudio is a sound server that mixes audio from multiple applications and passes it along to the sound hardware. It offers advanced features such as network transparency: an application can play a sound on a remote system, and PulseAudio makes it come out the speakers on the remote machine where the user is working. Supporting it shouldn't be a big change for most application developers to handle. It will handle applications written to the kernel's maintained audio API, ALSA, using the PulseAudio backend for alsa-lib. So the PulseAudio transition has been relatively painless for the distributions.

An earlier sound server project, the Enlightened Sound Daemon (ESD) sound server, is falling out of favor and Media Application Server (MAS) has never really caught on. However, one of the competing sound servers looks likely to remain. On the pro audio side, the low-latency sound server JACK is the recommended option. JACK, the "Jack Audio Connection Kit," as Dave Phillips writes, "holds the keys to the kingdom" for connecting studio applications such as the Ardour digital audio workstation and the Rosegarden MIDI sequencer. "If you want all of the features, no one audio system supports all of them," Lennart said.

Apple and Microsoft each have a single sound server that does both desktop and pro audio, but nobody at the session seemed to have much interest in that direction for Linux. PulseAudio is optimized for general desktop use and power savings, and supports scheduling features that should minimize wakeups but still allow for reasonably low-latency playback of streaming audio. It's also network-transparent and supports features such as placing desktop sound events based on mouse position. Network audio and desktop effects don't tempt pro audio users. JACK's uncompromising approach toward latency means it's likely to hog too much power to be acceptable to battery-life-watching desktop users, but fine for a studio with a rack full of gear. So two sound servers, one for pro and one for the masses, seems to be fine with both sets of users.

Abusing ALSA

PulseAudio, however, can't give applications direct access to the hardware, and currently only about 70% of ALSA applications use the API in a PulseAudio-safe way, Lennart said. Some high-profile applications are among those doing audio wrong. "Flash and Skype are really really broken applications, especially Flash," he said. Adobe split out the parts of its code that talk to the audio subsystem, and certain other plumbing, into an open-source library, libflashsupport. But Flash remains broken. The proprietary Flash library talks to libflashsupport from multiple threads, and one thread calls a destructor while another continues to send data. "It works until you close the browser window and then you get a race," Lennart said.

Developers who want to play audio have a sometimes-confusing choice of tools, including PortAudio and GStreamer. (PortAudio is cross-platform, which is likely why the popular cross-platform audio editing application Audacity uses it.) GStreamer is relatively feature-intense and heavyweight, also handling video and transcoding. (Write a player with Gstreamer and you get the ability to play your collection of C64 SID files for free.)

"If someone comes and says, 'I want to write an audio application. Which API should I use?' I don't have a good answer," Lennart said. The current best answer seems to be to write to the PulseAudio-safe subset of ALSA. Jeff Licquia of the Linux Standard Base (LSB), in the audience, mentioned that ALSA is on track for inclusion in LSB 4.0, and is a trial use module for 3.2. LSB aims to define a compatibility standard for Linux applications, and aims to do the kind of application developer education that Linux audio developers seem to need. Applications seeking LSB certification must run all of the LSB tests, but can fail anything tagged as trial use. "We're only keeping the stuff that we hope will be around for the long term," he said. If the LSB-safe subset of ALSA fits into the PulseAudio-safe subset of ALSA, application developers could write to ALSA and test with LSB.

"I would like to be able to tell people to use libsydney," Lennart said. Libsydney, in progress, is intended to be a networking-friendly general-purpose audio API.

ALSA and the HD-Audio widget problem

In ALSA, the hardware/software interface is in good shape, but software to user interface needs some work. Takashi Iwai, a core ALSA developer and Novell employee, pointed out in a talk that the line count for /sound code in the kernel is actually shrinking, except for ASoC (system on a chip) and HD-audio. "There will be no more sound cards, especially PCI," he said. The one exception is the SoundBlaster X-FI for gamers, which is currently not supported well in ALSA. Creative announced proprietary drivers in 2006, but one ALSA developer recently did get access to a data sheet under NDA.

The new audio standard, HD-Audio, is commonly found on new systems, and it's well-supported at the kernel level. However, it's based on "widgets" with vendor-configurable I/O pins. A driver can't tell how the HD-Audio part is connected, so some Linux plumbing work is required to identify which of the many exposed level controls is the right one to show the user. An audience member pointed out the need to tweak multiple level settings on his hardware, to get the right level without distortion. Linux will need more information on how each machine has its HD-Audio hardware hooked up in order to reliably give the user a useful volume control.

Comments (143 posted)

System Applications

Clusters and Grids

zc.async 1.5.0 released

Full Story (comments: none)

Database Software

LiquiBase: 1.8.0 Released (SourceForge)

Comments (none posted)

PostgreSQL 8.3.4, 8.2.10, etc. update release announced

Full Story (comments: none)

PostgreSQL Weekly News

Full Story (comments: none)

SQLite release 3.6.3 announced

Comments (none posted)

ZMySQLDA 3.0 for Zope 2

Full Story (comments: none)

Web Site Development

Introducing the Django Debug Toolbar

Comments (none posted)

WSO2 Web Service Framework for Jython 1.0-alpha released

Full Story (comments: none)

Miscellaneous

Rockbox 3.0 released

Full Story (comments: 1)

Desktop Applications

Desktop Environments

GNOME 2.24 available

Full Story (comments: 11)

GNOME Software Announcements

• Accerciser 1.4.0 (translation work)
• anjuta, gdl and gnome-build 2.24.0 (new features, bug fixes and translation work)
• at-spi 1.24.0 (bug fix and translation work)
• atk 1.24.0 (bug fix and translation work)
• Banshee 1.3.1 (new features and bug fixes)
• bug-buddy 2.24.0 (new features and translation work)
• cairo snapshot 1.7.6 (build changes, API changes and bug fixes)
• Cheese 2.24.0 (bug fixes and translation work)
• Deskbar-Applet 2.24.0 (bug fixes and translation work)
• Devhelp 0.21 (translation work)
• Ekiga 3.00 (new release series)
• Empathy 2.24.0 (bug fixes and translation work)
• Epiphany 2.24.0.1 (new features, bug fixes and translation work)
• Eye of GNOME 2.24.0 (bug fixes and translation work)
• fast-user-switch-applet 2.24.0 (bug fixes and translation work)
• File Roller 2.24.0 (bug fixes and translation work)
• F-Spot 0.5.0 (new features, bug fixes documentation and translation work)
• F-Spot 0.5.0.1 (bug fixes and translation work)
• Gcalctool 5.23.5 (translation work)
• GLib 2.18.1 (bug fixes and translation work)
• glibmm 2.18.0 (bug fix)
• gnome-applets 2.24.0 (new features, bug fixes and translation work)
• Gnome Games 2.24.0 (translation work)
• gnome-keyring 2.24.0 (new features and bug fixes)
• GNOME Media 2.24.0 (bug fixes and translation work)
• GNOME Media 2.24.1 (bug fixes)
• GNOME Power Manager 2.24.0 (bug fixes and translation work)
• gnome-settings-daemon 2.24.0 (bug fixes and translation work)
• GNOME Utilities 2.24.0 (bug fixes and translation work)
• GOK 2.24.0 (translation work)
• gthumb 2.10.10 (new features, bug fixes and translation work)
• GTK+ 2.14.2 (bug fixes and translation work)
• GTK+ 2.14.3 (bug fixes)
• Gtk2-Perl 2.24.0 (new features and bug fixes)
• gtk-engines 2.16.0 (bug fix and translation work)
• gtkmm 2.14.0 (new features and bug fixes)
• libgnomekdb 2.24.0 (bug fixes)
• Metacity 2.24. (bug fix and translation work)
• mousetweaks 2.24.0 (new features, bug fixes and translation work)
• Orca 2.24.0 (bug fixes and translation work)
• pessulus 2.24.0 (bug fixes and translation work)
• PyGoocanvas 0.12.0 (API update and documentation work)
• seahorse 2.24.0 (new features and bug fixes)
• seahorse-plugins 2.24.0 (code rework and bug fixes)
• Tomboy 0.12.0 (new features, bug fixes and translation work)
• Yelp 2.24.0 (bug fixes and translation work)

Comments (none posted)

KDE Commit-Digest for 14th September 2008 (KDE.News)

Comments (none posted)

KDE Software Announcements

• Beesoft Commander 4.1.0 (new features)
• cb2Bib 1.0.3 (new features)
• Elltube 0.1alpha (initial release)
• Elltube 0.1beta (new features)
• Elltube 0.1final (new features and bug fix)
• Folding@KDE 2.0 (unspecified)
• K Menu Gnome 0.7.4 (new features)
• Kate Gtags 1.4 (new features and code cleanup)
• KDE Partition Manager 1.0.0-ALPHA1 (initial release)
• kdesvn 1.0.1 (new features and bug fixes)
• kdesvn 1.0.2 (bug fix)
• KGRUBEditor 0.8.5b (bug fixes)
• kipi-plugins 0.2.0-beta1 (new feature and bug fixes)
• kssh-add 0.2 (bug fix)
• NoteFinder 0.1.3 (new feature and bug fixes)
• NoteFinder 0.1.4 (new feature and bug fix)
• PeaZip 2.3a (new features and translation work)
• PyQt3Support r3 (new features and code cleanup)
• Sinerji 0.1 (initial release)
• uspc 0.4 (unspecified)

Comments (none posted)

X.org 7.4 released

Comments (27 posted)

Xorg Software Announcements