The Grumpy Editor encounters the Hardy Heron

Your editor is not always known for making life easy for himself. Perhaps one of the most clear examples of masochistic behavior would be a certain preference for running development distributions on mission-critical systems. That said, your editor has stuck with a stable distribution on his laptop through a round of intensive travel earlier this year. But that was too easy, so, shortly before heading off to the Linux Foundation's Collaboration Summit, the laptop got moved to the Ubuntu "Hardy Heron" distribution. Needless to say, there have been some interesting ups and downs (literally) since then.

There is always a certain thrill that comes with upgrading a system and finding that important features no longer work. In this case, the problem was suspend and resume, which your editor uses heavily. In fact, the system would suspend just fine - as long as one failed to notice that, behind the cleverly darkened screen, the laptop's backlight had been left on. Needless to say, this new behavior is not helpful if one's goal is to save power while the system is suspended, but it gets worse than that. Your editor discovered this nice surprise after carrying the computer in a backpack for a few hours; by the time it came out, it was almost too hot to hold. Happily, no permanent damage appears to have been done.

Or, perhaps, unhappily. Your editor has been looking for an excuse to get a new laptop for a while.

The problem turned out to be a HAL configuration error combined with a strange internal model number which makes your editor's Thinkpad X31 different from, seemingly, every other X31 on the planet. Once your editor found the bug report and attached a "me too" comment, the solution was quick in coming. On the net, one can find complaints that Ubuntu is unresponsive to bug reports, but that was certainly not the experience here.

As an aside, it seems worth noting that life seems to have gotten more complicated, with a lot more code wrapped around the kernel than there once was. The problematic configuration file was /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-ibm.fdi - not a place where your editor, who is not a HAL expert, would have thought to look. That, it seems, is the price of more capable hardware and software, but sometimes your editor pines for the days when it seemed possible to carry a full understanding of the system within a single brain.

GNOME developers are (perhaps unjustly in recent years) known for taking a minimal approach to configuration options. That can be irritating, but just as annoying is their tendency to reset the options they do provide over major updates. Once suspend and resume work, your editor demands something else of a laptop when traveling: absolute silence. So the return of beeps to gnome-terminal was not appreciated. Those were easily silenced, but the GNOME developers also saw fit to bring back the blinking cursor - and they took away the configuration option which abolishes that intolerable feature.

Your editor first ran into the unstoppable blink with Rawhide; a query to the developers there turned up a quick answer. It seems that the GNOME developers have decided to create a single, system-wide parameter to control blinking cursors. Now, your editor approves of the concept of being able to turn off that behavior everywhere with a single switch - but only as long as that switch isn't hidden where nobody will ever find it. In this case, the GNOME developers have taken this feature, wrapped it in old newspapers, and stashed it behind the furnace in the basement; then they put a trunk on top of it. It is a rare user who will find it unassisted. In the hopes that it may save one or two readers from some time spent with search engine, your editor will now divulge the top-secret incantation which turns blinking cursors off:

    gconftool-2 --type bool --set /desktop/gnome/interface/cursor_blink false 

Naturally, a terminal window is required to run this command. It would have been nice if the developers who packaged this code for Hardy Heron had found a way to smooth over this change, but no such luck; as far as your editor can tell, no distributor has made that effort.

Another bit of fun is that your editor is no longer able to set the desktop background; the relevant configuration windows are ineffective. In this case, it would appear that the task of implementing the user's background choices have been moved to nautilus - just the place your editor would have thought to look for it. As it happens, your editor has no use for file managers and does not run nautilus - and is punished with an immutable Ubuntu-brown background for that sin. Happily, your editor still knows how to run xsetroot.

All of the above is a set of relatively minor grumbles, all of which are rectified in relatively short order. Once those details have been taken care of, the Hardy Heron release works quite well. One of the biggest aggravations from previous upgrades - having OpenOffice.org reformat the slides in all of your editor's presentations - was not present this time around. Hopefully we are moving into an era where "it didn't mangle my documents" is not something considered worthy of mention.

There was one very nice surprise as well. Your editor's laptop previously required almost 12 watts of power when running unplugged. This laptop is not at the bleeding edge of current technology, so the amount of time it was able to run without a recharge has been dropping for a while. With the Hardy release, steady-state power consumption has dropped to just over 9 watts - a big improvement. The credit for this change belongs to developers at all levels: kernel, applications, distributors, etc. The end result is a system which runs much more efficiently, and that is a good thing.

All told, your editor is reasonably content; this distribution looks like one which might just be worth keeping around. That's a good thing, since Ubuntu plans to maintain it as a "long-term support" release. Not that your editor intends to make much use of that long-term support; there should be a new development series starting soon, after all. One of the nice things about development distributions is that support never ends as long as one stays on the treadmill and the project itself remains alive.

Comments (163 posted)

ELC: A taste of the conference

Technical conferences generally provide a wealth of choices, to the point where participants have to make tough decisions at times to pick the session to sit in on. This year's Embedded Linux Conference was no exception; there were multiple slots where the author had to wish that he could be in more than one place at a time. But, he did manage to take notes in some of those that he attended; hopefully some of the conference flavor can come through in the following report.

Power management

MontaVista's Kevin Hilman presented an approach for handling power management on embedded devices that focused on changes that can be made to the kernel, but noted that there is much that can be done by applications too. Because of the time and money budgets available for embedded projects, many do not have the resources to do a complete job of tuning the kernel to get the best possible power performance. There is also no "one size fits all" solution for power management, there are too many device-specific issues to allow that.

Hilman's approach is to target specific "building blocks" that embedded developers can incorporate into their project. Each block will provide some savings, so the project can stop when the desired performance is reached—or it is time to ship the device. One of the easier steps is to customize the idle loop in the kernel, putting the processor to sleep when there is no work to be done. There are different kinds of sleep, though, generally trading off power savings and wakeup latency. The cpuidle subsystem provides a means to specify those values in an architecture independent way, which, along with a platform independent "governor", can put the processor into various sleep modes. The only platform dependent piece are the hooks to enter each of the different sleep states.

A similar approach is taken by the CPUfreq subsystem, which can reduce the clock frequency of the CPU to reduce power consumption using the Dynamic Voltage and Frequency Scaling (DVFS) feature of some processors. "Operating points" (OPs)—voltage and frequency tuples—are defined for the hardware. There are various generic CPUfreq governors that can then be used to determine when to change OPs and which to change to. The governor will invoke a platform-specific driver to effect that change. In addition, power management "quality of service" is currently being discussed to allow applications to request a certain level of performance that may override some of the lower-level sleep or frequency decisions.

Embedded SELinux

SELinux has a well-earned reputation for being able to restrict processes to only use those resources that have been specifically allowed by policy, but it is rather resource intensive. Yuichi Nakamura presented Hitachi's research into bringing SELinux into a more resource constrained embedded environment. One of the first problems they encountered was the need for flash filesystems that support extended attributes (xattrs), which is where SELinux stores labels for files. Only jffs2 currently supports xattrs, so that is the one they used.

The next big hurdle was trying to get a set of policies that were stripped down to the needs of an embedded platform. Nakamura started with the SELinux reference policy (refpolicy) and started removing rules. The sheer number of rules and policies that needed to be removed was daunting—as was the need to understand what was being removed. He also ran into strange dependencies: removing a sendmail policy caused a problem in the apache rules. The solution was to create a simplified policy language and policy editor that reduced the problem to something more tractable for the embedded world. In the process it greatly reduced the size of the policy files, from 4.6M down to 60K.

Another problem encountered was the performance and size of SELinux, which is a common embedded woe. Through some hand optimization of the read/write path, along with removing some unused permissions checks, they were able to increase the performance by a factor of ten on their SuperH reference platform. By changing some static buffers in SELinux to a dynamic allocation they also saved 250K of runtime memory. Much of that work was merged into 2.6.24. There is still work to be done, but with the changes, SELinux is viable for embedded platforms.

GCC and kernel hacking

Two sessions provided various tips and tricks for embedded development, with Gene Sally of Timesys focused on GCC, while IBM's Hugh Blemings shared some of the things he has learned from the kernel hackers he works with.

Sally discussed the different ways that developers could get a GCC toolchain for their target processor. One of the bigger hurdles that an embedded developer faces is getting a cross-compiler toolchain—one that runs on his development workstation, but generates code for the target platform. There are several ways to get the toolchain: as a tarball for popular development/target combinations, by using helper tools like crosstool or buildroot from uClibc, or by building it from source directly.

Building from source is the most difficult, of course, but allows for the most customizations and flexibility. Sally went on to describe a handful of useful GCC command-line options for helping to debug cross-compilers or just to better understand what GCC is doing:

• gcc -### - show what GCC would have executed
• gcc -v - show what GCC is executing
• gcc -g x.c -o x; objdump -S x - show the C and generated assembly code
• gcc -E -dM - </dev/null - show all predefined GCC macros
• gcc -C -E - show pre-processor output, but leave comments intact
• gcc -M - show all include file dependencies (for use in Makefiles)
• gcc -MM - like above, but ignore system include files

Blemings concentrated on the development infrastructure by describing the lab that he used to port the kernel to a Taishan PowerPC-based evaluation board. When undertaking a project like that, "get to know your hardware team" because they will have lots of important information and shortcuts that can be used as part of the board "bringup". At IBM in Canberra, where Blemings is based, they have gotten to the point where they can bring up Linux on any board where they can "access memory and point the PC [program counter] at it"; his tips have come out of that environment.

One of the most important things is to realize that you will be building kernels over and over again, so optimizing your environment for that will save lots of time. His suggestion was to start with a "honkin'" compile box; he described an IBM multi-processor box as an excellent choice but noted that the cost was so high he couldn't get one. It would, however, do "3k/sec"—that's compile 3 kernels per second. In the absence of something like that, he suggested borrowing cycles by using ccache and distcc to reduce and parallelize the compilation that needs to be done. Even adding relatively modest machines into the distcc pool can significantly reduce time spent waiting for a new kernel.

Ubuntu mobile and embedded (UME) and Maemo

One of the hottest areas in embedded Linux these days is the mobile internet device (MID) market. There were two talks on MID-focused distributions, with Canonical's David Mandala giving an overview of Ubuntu Mobile and Embedded (UME) and Nokia's Kate Alhola talking about the status and future directions of Maemo Mobile Linux. UME is a relatively recent addition to the mobile device space—they are anxiously awaiting hardware to run on—whereas Maemo has been around for a while, powering the Nokia N770, N800, and N810 internet tablets.

UME is an effort to apply the Ubuntu distribution and philosophy to touchscreen devices. Mandala explained that they are taking existing Linux applications and adapting them for small screens that use fingers, rather than keyboard and mouse, as the input device. The resolution of the displays is typically something approaching that of low-end desktops, but the physical space they take up is far smaller (i.e. the dots per inch or DPI is high) making it difficult to do development without actual hardware.

The UME project is working with Intel's Moblin.org project to target Atom processor based systems. It uses the Hildon application framework atop GNOME Mobile, running on an Ubuntu 8.04 (Hardy Heron) distribution. Mandala stressed that Linux should be "invisible" on these devices as users just want applications that work to browse the web, use email, and the like.

The main focus of UME has, so far, been on the user interface, though power consumption, memory footprint, and speeding up boot times are all on their radar. Canonical is very interested in fostering a community around UME, but that has been "a bit of a challenge", mostly due to a lack of hardware to run on. Mandala expects a few different hardware devices to be available "soon" and that will make it easier to attract a development community.

As should come as no surprise after Nokia's purchase of Trolltech early this year, Alhola announced that Maemo would be supporting both GTK and Qt in the near future. This is part of Nokia's belief that there is "no single truth", so Maemo supports multiple paths to development on the platform. Maemo directly supports C, C++, and Python, while the community has added support for Java, Objective C, Vala, and Mono.

Nokia makes a very clear distinction in its product line between phones, which are largely closed platforms, and tablets, which are open. Open source software is an essential part of their strategy as they want to build an application ecosystem around their products. "We are taking open source to the consumer mainstream," Alhola explains.

One of the interesting tools that Nokia is working on as part of Maemo is Scratchbox, which is a toolkit geared towards making cross-compilation easier. It does this by making the development environment look and act like the execution environment, using QEMU to simulate the target hardware. Scratchbox supports both ARM and x86 targets, with experimental support for additional architectures. It uses standard toolchains and distributions where possible and is released under the GPL.

LogFS

LogFS is a flash filesystem that is targeted at the larger flash devices that are becoming more widespread. Unlike some filesystems currently in use, most notably jffs2, LogFS is specifically designed to avoid some of the performance and scalability problems that come with larger devices. Jörn Engel is the developer of LogFS, with some support from the Consumer Electronics Linux Forum (sponsor of ELC), so he gave an update on the status of the project.

Engel used an unconventional scale (the sucks/rules meter) to measure the progress that had been made in the last year. The scale runs from -10 to 10 and measures the "suckiness" of particular features of the filesystem. Taking a page from This Is Spinal Tap, the score for the mount speed of LogFS was measured at 11 both last year and this. It is clearly the feature that Engel is most proud of as it takes 10-60ms to mount a filesystem; a similarly sized jffs2 takes on the order of one second.

Engel looked at around ten separate attributes of the filesystem, first rating them on where LogFS was a year ago, then re-rating based on where it is today. The conclusion is that the average measure has moved from -2.75 to -0.55, so that "on average, it hardly sucks". He says he is getting confident enough to submit it to Andrew Morton for inclusion in his tree, hopefully on its way into the mainline. Engel is clearly somewhat frustrated with people who are waiting until it is "done" to start using LogFS—though there are some fairly serious usability problems that would tend to limit testers—proclaiming: "LogFS is finished, try it now, today!"

In conclusion

There were more talks, of course, as well as an active "hallway track" for the roughly 175 participants. ELC is a well-run and very interesting conference that is worth consideration for anyone who uses, or plans to use, Linux as an embedded operating system. This year's venue, the Computer History Museum was a nice facility for a conference of this size. It also had some great exhibits that will bring back memories for anyone who has been using computers, calculators, or game systems over the past 50 years or so—well worth a visit when one is in Silicon Valley.

Comments (1 posted)

OLPC at a turning point

It looks like hard times for the One Laptop Per Child project. Quite a few key developers have left, including Mary Lou Jepsen, Ivan Krstić, Andres Salomon, and Walter Bender. Laptop deployments are far below the several million that the project had hoped for by this time, and many of the goals for the system's software have not been achieved. There is persistent talk of supporting Windows, with suggestions that Linux could be dropped altogether. An ongoing thread on the project's development mailing list shows that quite a few participants are concerned about where things are going. To many, it seems, OLPC is about to go down as a noble failure.

These rumors may be just a bit premature, though. When considering what may really come of OLPC, it's worth keeping a few things in mind.

One of those is the fact that the project has just completed a major push to its first mass-production system. Your editor has watched the project closely enough to see that, as with many such efforts, the people involved have been putting in lots of long hours to get the job done. When this kind of pressure is lifted, it is natural to take a break, catch up on the house work, and, perhaps, find a new job. So the departure of some key staff at this stage is not entirely surprising.

A look at the state of OLPC's software suggests that the project had set an overly ambitious set of goals for its first release. When that happens, one must jettison some objectives; the later that this is done, the more likely it is that the wrong objectives will be tossed overboard. There are signs that OLPC tried to do too much for too long, with an end result which is not as stable, as fast, or as fully-featured as one would like. As many people close to the project have noted, the laptop's software remains immature. But, as former president Walter Bender put it:

Finally, the number of laptops delivered to children is far below the level the project had planned upon. Fewer deployments means a lower impact for the project, but it also cannot be helping to create the economies of scale the project had counted on to push the cost down. There have also been some embarrassing failures along the way, including the misplacing of a large number of "Give one get one" orders until after it was too late to include them in the manufacturing run.

All of the above points to a need to make some changes in how the project is run. Changes always create uncertainty, so it would be surprising if OLPC participants were not a little nervous at the moment.

What happens in the next few months will likely determine OLPC's fate. The project's leadership has famously said in the past that OLPC is an education project, not a laptop project. Some people have recently expressed concerns that, in fact, OLPC is turning into a laptop project, with deployment numbers being the main goal. Nicholas Negroponte doesn't help when he allows himself to be quoted as being "mainly concerned with putting as many laptops as possible in children's hands." If OLPC becomes primarily a low-cost laptop vendor, and especially if it goes to proprietary operating systems as a means toward that end, it will lose much of the community that has grown up around the project.

And that would be a shame. There is great beauty in the idea of putting a well-designed learning tool into the hands of children and empowering those children by providing a system which is completely open and hackable. A large and motivated community of highly-capable people came together behind that vision and did their best to rethink how this technology should work and create something better. Deployment groups in a number of countries have gotten the resulting systems into the hands of thousands of children, and many of them are reporting good results. A lot of good things have happened here, and it doesn't have to end now.

But it might end soon. To pull things together, the project will have to communicate a clearer vision of where it plans to go with its software at all levels; Mr. Negroponte's statement of continued support for Sugar appears to be an attempt to start this process. The operational side of the project needs to get its act together. Some transparency on, for example, what is being done with donation money and what agreements have been made with outside corporations, would be most helpful. And, most of all, the group of volunteers working with this project have to be convinced anew that they are not wasting their time. If the project's leadership can manage all of that, there may well be great things coming from OLPC in the future.

Comments (8 posted)

Image handling vulnerabilities

Bugs that linger for eight years without a fix are probably annoying to whoever reported them; perhaps others as well. When those bugs have possible security implications, it is hard to see how they can remain unfixed for even eight months, let alone years, but that appears to be the case with some GTK image handling bugs. Code to handle image formats has been the source of numerous vulnerabilities along the way, which makes it even harder to see why these have languished so long.

A call for ideas for a hackfest on the GNOME foundation mailing list seems like a bit of a strange place to find information about vulnerabilities, but in the ensuing thread, Michael Chudobiak brought up some bugs that he would like to see addressed, perhaps as part of a hackfest:

The bugs he listed were from 2002 (80925), 2004 (142428), and 2008 (522803), but Alan Cox mentioned that he reported one of them as a GNOME security bug "about eight years ago". In his opinion all of the bugs were of the "well known, never fixed" variety. Because the code in question lives in GTK—used by many GNOME applications—"quite a few gnome apps fed small compressed images explode".

The basic problem is that the routines handling images create the full-resolution image in memory regardless of the size requested. In addition, various memory-intensive techniques are used to scale the image to the requested size. This impacts Nautilus and other GNOME programs that create thumbnails of large images.

Presumably, a denial of service, at a minimum, can result from these operations, though there may be other ways to exploit any program crashes that result. Cox has a plan to see them get fixed:

The vendor security list, often abbreviated vendor-sec, is a closed mailing list for distribution security teams to exchange information about vulnerabilities in various programs. It is closed so that bugs that are not publicly known can be freely discussed. Whether Cox's posting to that list spurs any action remains to be seen.

It is a rare week where LWN does not report some kind of image handling botch as a new vulnerability. This week, a cups vulnerability in handling PNG files could lead to a denial of service; last week we reported an Opera vulnerability in handling images in HTML canvas elements that could possibly lead to arbitrary code execution. Image handling is an area where all bugs need to be scrutinized carefully for potential security issues.

Hopefully, part of the problem is that the GNOME hackers did not realize the security implications of the bugs. There does seem to be ample complaint about performance problems, though, to get some kind of action over the last six or eight years. This is a set of related bugs that have seemingly been overlooked for a long time. Perhaps that time is now coming to an end.

Comments (2 posted)

clamav: buffer overflows

Package(s):	clamav	CVE #(s):	CVE-2008-0314 CVE-2008-1100
Created:	April 18, 2008	Updated:	July 17, 2008
Description:	Several remote vulnerabilities have been discovered in the Clam anti-virus toolkit.
Alerts:	Fedora FEDORA-2008-6422 clamav 2008-07-17 Gentoo 200805-19 clamav 2008-05-20 Fedora FEDORA-2008-3900 clamav 2008-05-14 Fedora FEDORA-2008-3420 clamav 2008-04-29 Mandriva MDVSA-2008:088 clamav 2007-04-17 Fedora FEDORA-2008-3358 clamav 2008-04-29 SuSE SUSE-SA:2008:024 clamav 2008-04-24 Debian DSA-1549-1 clamav 2008-04-17

Comments (none posted)

clamav: multiple vulnerabilities

Package(s):	clamav	CVE #(s):	CVE-2008-1387 CVE-2008-1833 CVE-2008-1835 CVE-2008-1836 CVE-2008-1837
Created:	April 18, 2008	Updated:	July 17, 2008
Description:	From the CVE entries: ClamAV before 0.93 allows remote attackers to cause a denial of service (CPU consumption) via a crafted ARJ archive, as demonstrated by the PROTOS GENOME test suite for Archive Formats. (CVE-2008-1387) Heap-based buffer overflow in libclamav in ClamAV 0.92.1 allows remote attackers to execute arbitrary code via a crafted WWPack compressed PE binary. (CVE-2008-1833) ClamAV before 0.93 allows remote attackers to bypass the scanning enging via a RAR file with an invalid version number, which cannot be parsed by ClamAV but can be extracted by Winrar. (CVE-2008-1835) The rfc2231 function in message.c in libclamav in ClamAV before 0.93 allows remote attackers to cause a denial of service (crash) via a crafted message that produces a string that is not null terminated, which triggers a buffer over-read. (CVE-2008-1836) libclamunrar in ClamAV before 0.93 allows remote attackers to cause a denial of service (crash) via crafted RAR files that trigger "memory problems," as demonstrated by the PROTOS GENOME test suite for Archive Formats. (CVE-2008-1837)
Alerts:	Fedora FEDORA-2008-6422 clamav 2008-07-17 Gentoo 200805-19 clamav 2008-05-20 Fedora FEDORA-2008-3900 clamav 2008-05-14 Fedora FEDORA-2008-3358 clamav 2008-04-29 Fedora FEDORA-2008-3420 clamav 2008-04-29 SuSE SUSE-SA:2008:024 clamav 2008-04-24 Mandriva MDVSA-2008:088 clamav 2007-04-17

Comments (none posted)

cups: arbitrary code execution

Package(s):	cups	CVE #(s):	CVE-2008-1722
Created:	April 21, 2008	Updated:	December 22, 2008
Description:	From the Gentoo advisory: Thomas Pollet reported a possible integer overflow vulnerability in the PNG image handling in the file filter/image-png.c. A malicious user might be able to execute arbitrary code with the privileges of the user running CUPS (usually lp), or cause a Denial of Service by sending a specially crafted PNG image to the print server. The vulnerability is exploitable via the network if CUPS is sharing printers remotely.
Alerts:	rPath rPSA-2008-0338-1 cups 2008-12-19 Ubuntu USN-656-1 cupsys 2008-10-15 Fedora FEDORA-2008-8844 cups 2008-10-16 Fedora FEDORA-2008-8801 cups 2008-10-16 Mandriva MDVSA-2008:170 cups 2007-08-13 Debian DSA-1625-1 cupsys 2008-08-01 CentOS CESA-2008:0498 cups 2008-06-04 Red Hat RHSA-2008:0498-01 cups 2008-06-04 Fedora FEDORA-2008-3756 cups 2008-05-13 Fedora FEDORA-2008-3586 cups 2008-05-09 Fedora FEDORA-2008-3449 cups 2008-05-09 Ubuntu USN-606-1 cupsys 2008-05-05 Gentoo 200804-23 cups 2008-04-18

Comments (none posted)

dbmail: authentication bypass

Package(s):	dbmail	CVE #(s):	CVE-2007-6714
Created:	April 21, 2008	Updated:	May 21, 2008
Description:	From the Gentoo advisory: A vulnerability in DBMail's authldap module when used in conjunction with an Active Directory server has been reported by vugluskr. When passing a zero length password to the module, it tries to bind anonymously to the LDAP server. If the LDAP server allows anonymous binds, this bind succeeds and results in a successful authentication to DBMail. By passing an empty password string to the server, an attacker could be able to log in to any account.
Alerts:	Fedora FEDORA-2008-4245 dbmail 2008-05-21 Fedora FEDORA-2008-3371 dbmail 2008-04-29 Fedora FEDORA-2008-3333 dbmail 2008-04-29 Gentoo 200804-24 dbmail 2008-04-18

Comments (none posted)

fedora-ds-admin: privilege escalation and arbitrary command execution

Package(s):	fedora-ds-admin	CVE #(s):	CVE-2008-0892 CVE-2008-0893
Created:	April 22, 2008	Updated:	April 23, 2008
Description:	From the CVE entries: The replication monitor CGI script (repl-monitor-cgi.pl) in Red Hat Administration Server, as used by Red Hat Directory Server 8.0 EL4 and EL5, allows remote attackers to execute arbitrary commands. Red Hat Administration Server, as used by Red Hat Directory Server 8.0 EL4 and EL5, does not properly restrict access to CGI scripts, which allows remote attackers to perform administrative actions.
Alerts:	Fedora FEDORA-2008-3214 fedora-ds-admin 2008-04-21 Fedora FEDORA-2008-3220 fedora-ds-admin 2008-04-21

Comments (none posted)

feh: shell command injection

Package(s):	feh	CVE #(s):
Created:	April 17, 2008	Updated:	April 23, 2008
Description:	feh has a vulnerability involving shell command injection using specially crafted file names.
Alerts:	Fedora FEDORA-2008-3068 feh 2008-04-17 Fedora FEDORA-2008-3064 feh 2008-04-17

Comments (none posted)

firefox: denial of service

Package(s):	firefox	CVE #(s):	CVE-2008-1380
Created:	April 17, 2008	Updated:	January 8, 2009
Description:	From the Red Hat alert: A flaw was found in the processing of malformed JavaScript content. A web page containing such malicious content could cause Firefox to crash or, potentially, execute arbitrary code as the user running Firefox.
Alerts:	Debian DSA-1696-1 icedove 2009-01-07 Gentoo 200808-03 mozilla-firefox 2008-08-06 SuSE SUSE-SR:2008:013 thunderbird, xulrunner, tkimg, cups, qemu, gstreamer010-plugins-good, pan, libxslt 2008-06-13 Mandriva MDVSA-2008:110 mozilla-firefox 2008-06-05 Gentoo 200805-18 mozilla-firefox 2008-05-20 Fedora FEDORA-2008-3557 thunderbird 2008-05-09 Fedora FEDORA-2008-3519 thunderbird 2008-05-09 SuSE SUSE-SR:2008:011 rsync, MozillaFirefox, poppler, nagios, lighttpd, sarg, squid, bzip2, kdelibs3, texlive-bin, kdelibs4, Sun Java 2008-05-09 Foresight FLEA-2008-0008-1 firefox 2008-05-08 CentOS CESA-2008:0224 thunderbird 2008-05-08 Fedora FEDORA-2008-3283 kazehakase 2008-04-22 Fedora FEDORA-2008-3283 devhelp 2008-04-22 Fedora FEDORA-2008-3283 gnome-web-photo 2008-04-22 Fedora FEDORA-2008-3283 yelp 2008-04-22 Fedora FEDORA-2008-3283 epiphany-extensions 2008-04-22 Fedora FEDORA-2008-3264 seamonkey 2008-04-22 Fedora FEDORA-2008-3249 Miro 2008-04-22 Fedora FEDORA-2008-3249 epiphany 2008-04-22 Debian DSA-1555-1 iceweasel 2008-04-23 Fedora FEDORA-2008-3283 ruby-gnome2 2008-04-22 Fedora FEDORA-2008-3283 firefox 2008-04-22 Fedora FEDORA-2008-3283 gtkmozembedmm 2008-04-22 Slackware SSA:2008-108-01 mozilla 2008-04-18 Red Hat RHSA-2008:0222-02 firefox 2008-04-16 Red Hat RHSA-2008:0224-01 thunderbird 2008-04-30 Debian DSA-1562-1 iceape 2008-04-28 Debian DSA-1558-1 xulrunner 2008-04-24 Fedora FEDORA-2008-3249 yelp 2008-04-22 Fedora FEDORA-2008-3249 liferea 2008-04-22 Fedora FEDORA-2008-3249 gtkmozembedmm 2008-04-22 Fedora FEDORA-2008-3249 gnome-python2-extras 2008-04-22 Fedora FEDORA-2008-3249 galeon 2008-04-22 Fedora FEDORA-2008-3249 devhelp 2008-04-22 Fedora FEDORA-2008-3249 openvrml 2008-04-22 Fedora FEDORA-2008-3249 epiphany-extensions 2008-04-22 Fedora FEDORA-2008-3249 firefox 2008-04-22 Fedora FEDORA-2008-3249 ruby-gnome2 2008-04-22 Fedora FEDORA-2008-3249 kazehakase 2008-04-22 Fedora FEDORA-2008-3249 chmsee 2008-04-22 Fedora FEDORA-2008-3231 seamonkey 2008-04-22 Fedora FEDORA-2008-3283 chmsee 2008-04-22 Fedora FEDORA-2008-3283 Miro 2008-04-22 Fedora FEDORA-2008-3283 openvrml 2008-04-22 Fedora FEDORA-2008-3283 galeon 2008-04-22 Fedora FEDORA-2008-3283 epiphany 2008-04-22 Fedora FEDORA-2008-3283 liferea 2008-04-22 Fedora FEDORA-2008-3283 gnome-python2-extras 2008-04-22 Ubuntu USN-602-1 firefox 2008-04-22 Red Hat RHSA-2008:0223-02 seamonkey 2008-04-16

Comments (none posted)

ikiwiki: cross-site request forgery

Package(s):	ikiwiki	CVE #(s):	CVE-2008-0165
Created:	April 21, 2008	Updated:	June 2, 2008
Description:	From the Debian advisory: It has been discovered that ikiwiki, a Wiki implementation, does not guard password and content changes against cross-site request forgery (CSRF) attacks.
Alerts:	Debian DSA-1553-2 ikiwiki 2008-06-01 Debian DSA-1553-1 ikiwiki 2008-04-20

Comments (none posted)

mplayer: arbitrary code execution

Package(s):	mplayer	CVE #(s):	CVE-2008-1558
Created:	April 21, 2008	Updated:	September 16, 2008
Description:	From the Debian advisory: It was discovered that the MPlayer movie player performs insufficient input sanitising on SDP session data, leading to potential execution of arbitrary code through a malformed multimedia stream.
Alerts:	Mandriva MDVSA-2008:196 mplayer 2008-09-15 Gentoo 200805-22 mplayer 2008-05-29 Debian DSA-1552-1 mplayer 2008-04-19

Comments (none posted)

mt-daapd: integer overflow

Package(s):	mt-daapd	CVE #(s):	CVE-2008-1771
Created:	April 23, 2008	Updated:	September 1, 2008
Description:	The mt-daapd music server suffers from an integer overflow enabling remote denial of service attacks and possibly code execution.
Alerts:	Debian DSA-1597-2 mt-daapd 2008-08-30 Debian DSA-1597-1 mt-daapd 2008-06-12 Fedora FEDORA-2008-4126 mt-daapd 2008-05-17 Fedora FEDORA-2008-3250 mt-daapd 2008-04-22

Comments (none posted)

openfire: denial of service

Package(s):	openfire	CVE #(s):	CVE-2008-1728
Created:	April 23, 2008	Updated:	April 23, 2008
Description:	The openfire (formerly wildfire) Jabber server cannot cope with clients which fail to read messages, leading to a denial of service vulnerability.
Alerts:	Gentoo 200804-26 openfire 2008-04-23

Comments (none posted)

openoffice.org: multiple vulnerabilities

Package(s):	openoffice.org	CVE #(s):	CVE-2007-5745 CVE-2007-5746 CVE-2007-5747 CVE-2008-0320
Created:	April 17, 2008	Updated:	September 10, 2008
Description:	From the Debian alert: CVE-2007-5745, CVE-2007-5747: Several bugs have been discovered in the way OpenOffice.org parses Quattro Pro files that may lead to a overflow in the heap potentially leading to the execution of arbitrary code. CVE-2007-5746: Specially crafted EMF files can trigger a buffer overflow in the heap that may lead to the execution of arbitrary code. CVE-2008-0320: A bug has been discovered in the processing of OLE files that can cause a buffer overflow in the heap potentially leading to the execution of arbitrary code.
Alerts:	Fedora FEDORA-2008-7531 openoffice.org 2008-09-05 Fedora FEDORA-2008-5247 openoffice.org 2008-06-11 Fedora FEDORA-2008-5239 openoffice.org 2008-06-11 Fedora FEDORA-2008-4104 openoffice.org 2008-05-17 Gentoo 200805-16 openoffice 2008-05-14 Ubuntu USN-609-1 openoffice.org 2008-05-06 Mandriva MDVSA-2008:095 openoffice.org 2008-05-02 SuSE SUSE-SA:2008:023 OpenOffice_org 2008-04-18 Red Hat RHSA-2008:0175-01 openoffice.org 2008-04-17 Fedora FEDORA-2008-3251 openoffice.org 2008-04-22 Mandriva MDVSA-2008:090 OpenOffice.org 2008-04-20 Debian DSA-1547-1 openoffice.org 2008-04-17

Comments (none posted)

php-toolkit: denial of service

Package(s):	php-toolkit	CVE #(s):	CVE-2008-1734
Created:	April 18, 2008	Updated:	April 23, 2008
Description:	From the Gentoo advisory: Toni Arnold, David Sveningsson, Michal Bartoszkiewicz, and Joseph reported that php-select does not quote parameters passed to the "tr" command, which could convert the "-D PHP5" argument in the "APACHE2_OPTS" setting in the file /etc/conf.d/apache2 to lower case.
Alerts:	Gentoo 200804-19 php-toolkit 2008-04-17

Comments (none posted)

poppler: arbitrary code execution

Package(s):	poppler	CVE #(s):	CVE-2008-1693
Created:	April 17, 2008	Updated:	September 17, 2008
Description:	From the Gentoo alert: Poppler does not handle fonts inside PDF files safely, allowing for execution of arbitrary code.
Alerts:	Mandriva MDVSA-2008:197-1 koffice 2008-09-16 Mandriva MDVSA-2008:197 koffice 2008-09-15 Mandriva MDVSA-2008:173 kdegraphics 2008-08-19 SuSE SUSE-SR:2008:013 thunderbird, xulrunner, tkimg, cups, qemu, gstreamer010-plugins-good, pan, libxslt 2008-06-13 SuSE SUSE-SR:2008:011 rsync, MozillaFirefox, poppler, nagios, lighttpd, sarg, squid, bzip2, kdelibs3, texlive-bin, kdelibs4, Sun Java 2008-05-09 CentOS CESA-2008:0262 gpdf 2008-05-08 Red Hat RHSA-2008:0262-01 gpdf 2008-05-08 Fedora FEDORA-2008-3312 poppler 2008-04-29 Ubuntu USN-603-2 koffice 2008-04-17 Ubuntu USN-603-1 poppler 2008-04-17 Red Hat RHSA-2008:0239-01 poppler 2008-04-17 Red Hat RHSA-2008:0238-01 kdegraphics 2008-04-17 Debian DSA-1548-1 xpdf 2008-04-17 Mandriva MDVSA-2008:089 poppler 2008-04-17 Red Hat RHSA-2008:0240-01 xpdf 2008-04-17 Gentoo 200804-18:02 poppler 2008-04-17

Comments (none posted)

python2.4: arbitrary code execution

Package(s):	python2.4	CVE #(s):	CVE-2008-1887
Created:	April 21, 2008	Updated:	August 25, 2009
Description:	From the Debian advisory: CVE-2008-1887: Justin Ferguson discovered that insufficient input validation in PyString_FromStringAndSize() may lead to the execution of arbitrary code.
Alerts:	rPath rPSA-2009-0122-1 python 2009-08-24 CentOS CESA-2009:1176 python 2009-07-29 CentOS CESA-2009:1178 python 2009-07-27 Red Hat RHSA-2009:1176-01 python 2009-07-27 Red Hat RHSA-2009:1177-01 python 2009-07-27 Red Hat RHSA-2009:1178-02 python 2009-07-27 SuSE SUSE-SR:2008:017 powerdns, dnsmasq, python, mailman, ruby, Opera, neon, rxvt-unicode, perl, wireshark, namazu, gnome-screensaver, mysql 2008-08-29 Ubuntu USN-632-1 python2.4, python2.5 2008-08-01 Debian DSA-1620-1 python2.5 2008-07-27 Gentoo 200807-01 python 2008-07-01 Debian DSA-1551-1 python2.4 2008-04-19

Comments (none posted)

speex: insufficient boundary checks

Package(s):	speex	CVE #(s):	CVE-2008-1686
Created:	April 17, 2008	Updated:	August 7, 2008
Description:	The speex speech codec has insufficient boundary checking in speex_packet_to_header().
Alerts:	Ubuntu USN-635-1 xine-lib 2008-08-06 Mandriva MDVSA-2008:124 xine-lib 2008-06-26 SuSE SUSE-SR:2008:013 thunderbird, xulrunner, tkimg, cups, qemu, gstreamer010-plugins-good, pan, libxslt 2008-06-13 SuSE SUSE-SR:2008:012 xine, xemacs, emacs, opensuse-updater, libvorbis, vorbis-tools, pdns-recursor, openwsman 2008-06-06 Debian DSA-1586-1 xine-lib 2008-05-22 Debian DSA-1584-1 libfishsound 2008-05-21 Fedora FEDORA-2008-3117 libfishsound 2008-05-17 Ubuntu USN-611-3 gst-plugins-good0.10 2008-05-08 Ubuntu USN-611-2 vorbis-tools 2008-05-08 Ubuntu USN-611-1 speex 2008-05-08 Mandriva MDVSA-2008:094 speex 2007-04-29 Mandriva MDVSA-2008:092 gstreamer-plugins-good 2008-04-29 Mandriva MDVSA-2008:093 vorbis-tools 2008-04-29 Slackware SSA:2008-111-01 xine 2008-04-22 Red Hat RHSA-2008:0235-01 speex 2008-04-16 Gentoo 200804-17 speex 2008-04-17 Fedora FEDORA-2008-3059 libfishsound 2008-04-17 Fedora FEDORA-2008-3103 speex 2008-04-17 Fedora FEDORA-2008-3191 speex 2008-04-17

Comments (none posted)

sun java: multiple vulnerabilities

Package(s):	sun-jre, sun-jdk	CVE #(s):	CVE-2007-5689 CVE-2007-5237 CVE-2008-0628
Created:	April 18, 2008	Updated:	April 28, 2008
Description:	From the CVE entries: The Java Virtual Machine (JVM) in Sun Java Runtime Environment (JRE) in SDK and JRE 1.3.x through 1.3.1_20 and 1.4.x through 1.4.2_15, and JDK and JRE 5.x through 5.0 Update 12 and 6.x through 6 Update 2, allows remote attackers to execute arbitrary programs, or read or modify arbitrary files, via applets that grant privileges to themselves. (CVE-2007-5689) Java Web Start in Sun JDK and JRE 6 Update 2 and earlier does not properly enforce access restrictions for untrusted applications, which allows user-assisted remote attackers to read and modify local files via an untrusted application, aka "two vulnerabilities." (CVE-2007-5237) The XML parsing code in Sun Java Runtime Environment JDK and JRE 6 Update 3 and earlier processes external entity references even when the "external general entities" property is false, which allows remote attackers to conduct XML external entity (XXE) attacks and cause a denial of service or access restricted resources. (CVE-2008-0628)
Alerts:	Red Hat RHSA-2008:0245-01 java-1.6.0-bea 2008-04-28 Gentoo 200804-20 sun-jre, sun-jdk 2008-04-17

Comments (none posted)

suphp: privilege escalation

Package(s):	suphp	CVE #(s):	CVE-2008-1614
Created:	April 18, 2008	Updated:	April 23, 2008
Description:	suPHP before 0.6.3 allows local users to gain privileges via (1) a race condition that involves multiple symlink changes to point a file owned by a different user, or (2) a symlink to the directory of a different user, which is used to determine privileges.
Alerts:	Debian DSA-1550-1 suphp 2008-04-17

Comments (none posted)

vlc: multiple vulnerabilities

Package(s):	vlc	CVE #(s):	CVE-2008-1881 CVE-2008-1489 CVE-2008-1768 CVE-2008-1769
Created:	April 23, 2008	Updated:	June 18, 2009
Description:	The latest set of vulnerabilities in vlc include a stack-based buffer overflow in the subtitle code (CVE-2008-1881), an integer overflow vulnerability in the MP4 code leading to a heap overflow (CVE-2008-1489), more integer overflows (CVE-2008-1768), and a "boundary error" in Cinepak leading to memory corruption (CVE-2008-1769).
Alerts:	Debian DSA-1819-1 vlc 2009-06-18 Gentoo 200804-25 vlc 2008-04-23

Comments (none posted)

WebKit: cross-site scripting and code execution

Package(s):	WebKit	CVE #(s):	CVE-2008-1010 CVE-2008-1011
Created:	April 23, 2008	Updated:	April 30, 2008
Description:	The WebKit browser engine suffers from a buffer overflow leading to arbitrary code execution and a cross-site scripting vulnerability; some more information is available from this summary.
Alerts:	Fedora FEDORA-2008-3415 midori 2008-04-29 Fedora FEDORA-2008-3415 WebKit 2008-04-29 Fedora FEDORA-2008-3229 kazehakase 2008-04-22 Fedora FEDORA-2008-3229 midori 2008-04-22 Fedora FEDORA-2008-3229 WebKit 2008-04-22

Comments (none posted)

Kernel release status

The 2.6.26 merge window is open, so there is no current 2.6 development release. See the article below for a summary of the patches merged for 2.6.26 so far.

The current -mm tree is 2.6.25-mm1. Recent changes to -mm include some read-copy-update enhancements and the OLPC architecture support code, but mostly -mm is just getting ready for the big flow of patches into the mainline. See the -mm merge plans document for Andrew's plans for 2.6.26.

The current stable 2.6 kernel is 2.6.25, released on April 16. After nearly three months of development and the merging of over 12,000 patches from almost 1200 developers, this kernel is now considered ready for wider use. Highlights of this release include the ath5k (Atheros wireless) driver, a bunch of realtime work including realtime group scheduling, preemptable RCU, LatencyTop support, a number of new ext4 filesystem features, support for the controller area network protocol, more network namespace work, the return of the timerfd() system call, the page map patches (providing much better information on system memory use), the SMACK security module, better kernel support for Intel and ATI R500 graphics chipsets, the memory use controller, ACPI thermal regulation support, MN10300 architecture support, and much more. See the KernelNewbies 2.6.25 page for lots of details, or the full changelog for unbelievable amounts of detail.

2.6.24.5 was released on April 18. It contains a relatively long list of fixes for significant 2.6.24 problems.

For older kernels: 2.4.36.3 was released on April 19. "Nothing outstanding here, I've just decided to release pending fixes. Those already running 2.4.36.2 have no particular reason to upgrade, unless they already experience troubles in the fixed areas."

Comments (1 posted)

Quotes of the week

-- Keith Packard

-- Andrew Morton

-- Ingo Molnar

Comments (none posted)

The 2.6.26 merge window opens

That shiny new 2.6.25 kernel which was released on April 16 is now ancient history; some 3500 changesets have been merged into the mainline git repository since then. Some of the most significant user-visible changes include:

• New drivers for Korina (IDT rc32434) Ethernet MACs, SuperH MX-G and SH-MobileR2 CPUs, Solution Engine SH7721 boards, ARM YL9200, Kwikbyte KB9260, Olimex SAM9-L9260, and emQbit ECB_AT91 boards, Digi ns921x processors, the Nias Digital SMX crypto engines, AMCC PPC460EX evaluation boards, Emerson KSI8560 boards, Wind River SBC8641D boards, Logitech Rumblepad 2 force-feedback devices, Renesas SH7760 I2C controllers, and SuperH Mobile I2C controllers.

• The PCI subsystem now supports PCI Express Active State Power Management, which can yield significant power savings on suitably equipped hardware.

• There is a new security= boot parameter which allows the specification of which security module to use if more than one are available.

• Network address translation (NAT) is now supported for the SCTP, DCCP, and UDP-Lite protocols. There is also netfilter connection tracking support for DCCP.

• The network stack can now negotiate selective acknowledgments and window scaling even when syncookies are in use.

• Another long series of network namespace patches has been merged, continuing the long process of making all networking code namespace-aware.

• Mesh networking support has been added to the mac80211 layer. It is currently marked "broken," though, until various outstanding issues are fixed.

• 4K stacks are now the default for the x86 architecture. This change is controversial and could be reversed by the time the final release happens.

• SELinux now supports "permissive types" which allow specific domains to run as if SELinux were not present in the system at all.

• A number of enhancements have been made to the realtime group scheduler, including multi-level groups, the ability to mix processes and groups (and have them compete against each other for CPU time), better SMP balancing, and more.

• Support for the running of SunOS and Solaris binaries has been removed; it has long been unmaintained and did not work well.

• The kernel now has support for read-only bind mounts, which provide a read-only view into an otherwise writable filesystem. This feature (the implementation of which was more involved than one might think) is intended for use in containers and other situations where even processes running as root should not be able to modify certain filesystems.

Changes visible to kernel developers include:

• At long last, support for the KGDB interactive debugger has been added to the x86 architecture. There is a DocBook document in the Documentation directory which provides an overview on how to use this new facility.

• Page attribute table (PAT) support is also (again, at long last) available for the x86 architecture. PATs allow for fine-grained control of memory caching behavior with more flexibility than the older MTRR feature. See Documentation/x86/pat.txt for more information.

• Two new functions (inode_getsecid() and ipc_getsecid()), added to support security modules and the audit code, provide general access to security IDs associated with inodes and IPC objects. A number of superblock-related LSM callbacks now take a struct path pointer instead of struct nameidata. There is also a new set of hooks providing generic audit support in the security module framework.

• The now-unused ieee80211 software MAC layer has been removed; all of the drivers which needed it have been converted to mac80211. Also removed are the sk98lin network driver (in favor of skge) and bcm43xx (replaced by b43 and b43legacy).

• The generic semaphores patch has been merged. The semaphore code also has new down_killable() and down_timeout() functions.

• The ata_port_operations structure used by libata drivers now supports a simple sort of operation inheritance, making it easier to write drivers which are "almost like" existing code, but with small differences.

• A new function (ns_to_ktime()) converts a time value in nanoseconds to ktime_t.

• The final users of struct class_device have been converted to use struct device instead. If all goes well, the class_device structure will be removed later in the 2.6.26 cycle.

• Greg Kroah-Hartman is no longer the PCI subsystem maintainer, having passed that responsibility on to Jesse Barnes.

• The seq_file code now accepts a return value of SEQ_SKIP from the show() callback; that value causes any accumulated output from that call to be discarded.

Needless to say, this development series is still young and, as of this writing, the merge window has over a week to run. So there will be a lot more code going into the mainline before the shape of 2.6.26 becomes clear.

Comments (1 posted)

4K stacks by default?

The kernel stack is a rather important chunk of memory in any Linux system. The unpleasant kernel memory corruption that results from overflowing it is something that is to be avoided at all costs. But the stack is allocated for each process and thread in the system, so those who are looking to reduce memory usage target the 8K stack used by default on x86. In addition, an 8K stack requires two physically contiguous pages (an "order 1" allocation) which can be difficult to satisfy on a running system due to fragmentation.

Linux has had optional support for 4K stacks for nearly four years now, with Fedora and RHEL enabling it on the kernels they ship, but a recent patch to make it the default for x86 has raised some eyebrows. Andrew Morton sees it as bypassing the normal patch submission process:

It is not surprising that patch author Ingo Molnar sees things a little differently:

As described in an earlier LWN article, the main concerns about only providing 4K for the kernel stack are for complicated storage configurations or for people using NDISwrapper. There is fairly high disdain for the latter case—as it is done to load proprietary Windows drivers into the kernel—but it could lead to a pretty hideous failure in the former. Data corruption certainly seems like a possibility, but, regardless, a kernel crash is definitely not what an administrator wants to have to deal with.

Arjan van de Ven summarized the current state, noting that NDISwrapper really requires 12K stacks, so having 8K only makes it less likely those kernels will crash. The stacking of multiple storage drivers (network filesystems, device mapper, RAID, etc.) is a bigger issue:

Proponents of default 4K stacks seem to be puzzled why there is objection to the change since there have been no problems with Red Hat kernels. But Andi Kleen notes:

The xfs filesystem, which is not supported in RHEL or Fedora, can potentially use a great deal of stack. This leads some kernel hackers to worry that a complicated configuration that uses it, an "nfs+xfs+md+scsi writeback" configuration as Eric Sandeen puts it, could overflow. Work is already proceeding to reduce the xfs stack usage, but it clearly is a problem that xfs hackers have seen. David Chinner responds to a question about stack overflows:

It would seem premature to make 4K stacks the default. There is good reason to believe that folks using xfs could run into problems. But there is a larger issue, one that Morton brought up in his initial message, then reiterated later in the thread:

The memory savings can be significant, especially in the embedded world. Coupled with the elimination of order 1 allocations each time a process gets created, there is good reason to keep working toward 4K stacks by default. As of this writing, the default remains for 4K stacks in Linus's tree, but that could change before long.

Comments (26 posted)

ELC: Morton and Saxena on working with the kernel community

In many ways, Andrew Morton's keynote set the tone for this year's Embedded Linux Conference (ELC) by describing the ways that embedded companies and developers can work with the kernel community in a way that will be "mutually beneficial". Morton provided reasons, from a purely economic standpoint, why it makes sense for companies to get their code into the mainline kernel. He also provided concrete suggestions on how to make that happen. The theme of the conference seemed to be "working with the community" and Morton's speech provided an excellent example of how and why to do just that.

Conference organizer Tim Bird introduced the keynote as "the main event" for ELC, noting that he often thought of Morton as "kind of like the adult in the room" on linux-kernel. Readers of that mailing list tend to get the impression that there's more than one of him around because of all that he does. He also noted that it was surprising to some that Morton has an embedded Linux background—from his work at Digeo.

Morton believes that embedded development is underrepresented in kernel.org work relative to its economic importance. This is caused by a number of factors, not least the financial constraints under which much embedded development is done. An exceptional case is the chip and board manufacturers who have a big interest in seeing Linux run well on their hardware so that they can attract more customers. But even those do not contribute as much as he would like to see to kernel development.

An effect of this underrepresentation is a risk that it will tilt kernel development more toward the server and desktop. The kernel team is already accused of being server-centric, and there is some truth to that, "but not as much as one might think". Kernel hackers do care about the desktop as well as embedded devices, but without an advocate for embedded concerns, sometimes things get missed.

Something Morton would like to see is a single full-time "embedded maintainer". That person would serve as the advocate for embedded concerns, ensuring that they didn't get overlooked in the process. An embedded maintainer could make a significant impact for embedded development.

Not all kernel contributions need to be code, he said. There is a need just to hear the problems that are being faced by the embedded community along with lists of things that are missing. "Senior, sophisticated people" are needed to help prioritize the features that are being considered as well. Morton often finds out things he didn't know at conferences, things that he should have known about much earlier: "That's bad!"

Morton is trying to incite the embedded community to interact with the kernel hackers more on linux-kernel. He said that a great way to get the attention of the team is to come onto the mailing list and make them look bad. Unfavorable comparisons to other systems or earlier kernels, for example, especially when backed up with numbers, are noticed quickly. He said that it is important to remember that the person who makes the most noise gets the most attention.

One of the areas that he is most concerned about is the practice of "patch hoarding"—holding on to kernel changes as patches without submitting them upstream to the kernel hackers. It is hopefully only due to a lack of resources, but he has heard that some are doing it to try and gain a competitive advantage. This is simply wrong, he said, companies have a "moral if not legal obligation" to submit those patches.

[PULL QUOTE: The code will be better because of the review done by the kernel hackers; once it is done, the maintenance cost falls to near zero as well. He also touted the competitive advantage, noting that getting your code merged means that you have won—competing proposals won't get in. END QUOTE]

There are many good reasons for getting code merged upstream that Morton outlined. The code will be better because of the review done by the kernel hackers; once it is done, the maintenance cost falls to near zero as well. He also touted the competitive advantage, noting that getting your code merged means that you have won—competing proposals won't get in. Being the first to merge a feature can make it easier on yourself and harder on your competition.

There are downsides to getting your code upstream as well. Most of those stem from not getting code out there early enough for review. The kernel developers can ask for significant changes to the code especially in the area of user space interfaces. If a company already has lots of code using the new feature and/or interface, it could be very disruptive; "sorry, there's no real fix for that except getting your code out early enough".

Another downside that companies may run into is with competitors being brought into the process. Morton and other kernel hackers will try to find others who might have a stake in a new feature to get them involved so that everybody's needs are taken into account. This can blunt the "win" of getting your feature merged. Some are also concerned that competitors will get access to the code once it has been submitted; "tough luck" Morton said, everything in the kernel is GPL.

Morton had specific suggestions for choosing a kernel version to use for an embedded project. 2.6.24 is not a lot better than 2.4.18 for embedded use, but it has one important feature: the kernel team will be interested in bugs in the current kernel. He suggests starting with the current kernel, upgrading it while development proceeds, freezing it only when it is time to ship the product.

He also suggests that a company create an internal kernel team with one or two people who are the interface to linux-kernel. This will help with name recognition on the mailing list, which will in turn get patches submitted more attention. Over time, by participating and reviewing others' code, the interface people will build up "brownie points" that will allow them to call in favors to get their code reviewed, or to help smooth the path for inclusion.

The kernel.org developers appear to give free support, generally very good support, Morton said, but it is not truly free. Kernel hackers do it as a "mutually beneficial transaction"; they don't do it to make more money for your company, they do it to make the kernel better. Morton is definitely a big part of that, inviting people to email him, especially if "five minutes of my time can save months of yours".

The decision about when to merge a new feature is hard for some to understand. Many consider Linux a dictatorship, which is incorrect, it is instead "a democracy that doesn't vote". The merge decision is made on the model of the "rule of law" with kernel hackers playing the role of judges. Unfortunately, there are few written rules.

Some of the factors that go into his decision about a particular feature are its maintainability, whether there will be an ongoing maintenance team, as well as the general usefulness of the feature. Depending on the size of the feature, an ongoing maintenance team can be the deciding factor. It is not so important for a driver, but a new architecture, for example, needs ongoing maintenance that can only be done by people with knowledge of and access to the hardware.

MontaVista kernel hacker, Deepak Saxena, gave a presentation entitled "Appropriate Community Practices: Social and Technical Advice" later in the conference that mirrored many of Morton's points. He showed some examples of hardware vendors making bad decisions that got shot down by the kernel developers, mostly because they didn't "release early and release often". There is a dangerous attitude that "it's Linux, it's open source, I can do anything I want" which is true, but won't get you far with the community.

Saxena has high regard for the benefits of working with the system: if your competitor is active in the community, they are getting an advantage that you aren't. Like Morton, he believes that some members of the development team need to get involved in kernel.org activities. "The community is an extension of your team, your team is an extension of the community".

He also has specific advice for hardware vendors: avoid abstraction layers, recognize that your hardware is not unique, and think beyond the reference board implementation. Generalizing your code so that others can use it will make it much more acceptable, as will talking with the developers responsible for the subsystems you are touching. Abstraction layers may be helpful for hardware vendors trying to support multiple operating systems, but they make it difficult for the kernel hackers to understand and maintain the code. The kernel.org folks are not interested in finding and fixing bugs in an abstraction layer.

He also points out additional benefits of getting code merged. Once it is in the kernel, the company's team will no longer have to keep up with kernel releases, updating their patches to follow the latest changes. The code will still need to be maintained, but day-to-day changes will be handled by the kernel.org folks. An additional benefit is that the code will be enhanced by various efforts to automatically find bugs in mainline kernel code with tools like lockdep.

It is clear that the kernel hackers are making a big effort to not only get code from the embedded folks, but also some of their expertise. There are various outreach efforts to try and get more people involved in the Linux development process; these two talks are certainly a part of that. By making it clear that there are benefits to both parties, they hope to make an argument that will reach up from engineering to management resulting in a better kernel for all.

Comments (27 posted)

Integrating and Validating dynticks and Preemptable RCU

Introduction

Read-copy update (RCU) is a synchronization mechanism that was added to the Linux kernel in October of 2002. RCU is most frequently described as a replacement for reader-writer locking, but it has also been used in a number of other ways. RCU is notable in that RCU readers do not directly synchronize with RCU updaters, which makes RCU read paths extremely fast, and also permits RCU readers to accomplish useful work even when running concurrently with RCU updaters.

In early 2008, a preemptable variant of RCU was accepted into mainline Linux in support of real-time workloads, a variant similar to the RCU implementations in the -rt patchset since August 2005. Preemptable RCU is needed for real-time workloads because older RCU implementations disable preemption across RCU read-side critical sections, resulting in excessive real-time latencies.

However, one disadvantage of the -rt implementation was that each grace period required work to be done on each CPU, even if that CPU is in a low-power “dynticks-idle” state, and thus incapable of executing RCU read-side critical sections. The idea behind the dynticks-idle state is that idle CPUs should be physically powered down in order to conserve energy. In short, preemptable RCU can disable a valuable energy-conservation feature of recent Linux kernels. Although Josh Triplett and Paul McKenney had discussed some approaches for allowing CPUs to remain in low-power state throughout an RCU grace period (thus preserving the Linux kernel's ability to conserve energy), matters did not come to a head until Steve Rostedt integrated a new dyntick implementation with preemptable RCU in the -rt patchset.

This combination caused one of Steve's systems to hang on boot, so in October, Paul coded up a dynticks-friendly modification to preemptable RCU's grace-period processing. Steve coded up rcu_irq_enter() and rcu_irq_exit() interfaces called from the irq_enter() and irq_exit() interrupt entry/exit functions. These rcu_irq_enter() and rcu_irq_exit() functions are needed to allow RCU to reliably handle situations where a dynticks-idle CPUs is momentarily powered up for an interrupt handler containing RCU read-side critical sections. With these changes in place, Steve's system booted reliably, but Paul continued inspecting the code periodically on the assumption that we could not possibly have gotten the code right on the first try.

Paul reviewed the code repeatedly from October 2007 to February 2008, and almost always found at least one bug. In one case, Paul even coded and tested a fix before realizing that the bug was illusory, but in all cases, the “bug” was in fact illusory.

Near the end of February, Paul grew tired of this game. He therefore decided to enlist the aid of Promela and spin, as described in the LWN article Using Promela and Spin to verify parallel algorithms. This article presents a series of seven increasingly realistic Promela models, the last of which passes, consuming about 40GB of main memory for the state space.

More important, Promela and Spin did find a very subtle bug for me!!!

This article is organized as follows:

1. Introduction to Preemptable RCU and dynticks
   1. Task Interface
   2. Interrupt Interface
   3. Grace-Period Interface
2. Validating Preemptable RCU and dynticks
   1. Basic Model
   2. Validating Safety
   3. Validating Liveness
   4. Interrupts
   5. Validating Interrupt Handlers
   6. Validating Nested Interrupt Handlers
   7. Validating NMI Handlers

These sections are followed by conclusions and answers to the Quick Quizzes.

Introduction to Preemptable RCU and dynticks

The per-CPU dynticks_progress_counter variable is central to the interface between dynticks and preemptable RCU. This variable has an even value whenever the corresponding CPU is in dynticks-idle mode, and an odd value otherwise. A CPU exits dynticks-idle mode for the following three reasons:

1. to start running a task,
2. when entering the outermost of a possibly nested set of interrupt handlers, and
3. when entering an NMI handler.

Preemptable RCU's grace-period machinery samples the value of the dynticks_progress_counter variable in order to determine when a dynticks-idle CPU may safely be ignored.

The following three sections give an overview of the task interface, the interrupt/NMI interface, and the use of the dynticks_progress_counter variable by the grace-period machinery.

Task Interface

When a given CPU enters dynticks-idle mode because it has no more tasks to run, it invokes rcu_enter_nohz():

  1 static inline void rcu_enter_nohz(void)
  2 {
  3   mb();
  4   __get_cpu_var(dynticks_progress_counter)++;
  5   WARN_ON(__get_cpu_var(dynticks_progress_counter) & 0x1);
  6 }

This function simply increments dynticks_progress_counter and checks that the result is even, but first executing a memory barrier to ensure that any other CPU that sees the new value of dynticks_progress_counter will also see the completion of any prior RCU read-side critical sections.

Similarly, when a CPU that is in dynticks-idle mode prepares to start executing a newly runnable task, it invokes rcu_exit_nohz:

  1 static inline void rcu_exit_nohz(void)
  2 {
  3   __get_cpu_var(dynticks_progress_counter)++;
  4   mb();
  5   WARN_ON(!(__get_cpu_var(dynticks_progress_counter) & 0x1));
  6 }

This function again increments dynticks_progress_counter, but follows it with a memory barrier to ensure that if any other CPU sees the result of any subsequent RCU read-side critical section, then that other CPU will also see the incremented value of dynticks_progress_counter. Finally, rcu_exit_nohz() checks that the result of the increment is an odd value.

The rcu_enter_nohz() and rcu_exit_nohz functions handle the case where a CPU enters and exits dynticks-idle mode due to task execution, but does not handle interrupts, which are covered in the following section.

Interrupt Interface

The rcu_irq_enter() and rcu_irq_exit() functions handle interrupt/NMI entry and exit, respectively. Of course, nested interrupts must also be properly accounted for. The possibility of nested interrupts is handled by a second per-CPU variable, rcu_update_flag, which is incremented upon entry to an interrupt or NMI handler (in rcu_irq_enter()) and is decremented upon exit (in rcu_irq_exit()). In addition, the pre-existing in_interrupt() primitive is used to distinguish between an outermost or a nested interrupt/NMI.

Interrupt entry is handled by the rcu_irq_enter shown below:

  1 void rcu_irq_enter(void)
  2 {
  3   int cpu = smp_processor_id();
  4 
  5   if (per_cpu(rcu_update_flag, cpu))
  6     per_cpu(rcu_update_flag, cpu)++;
  7   if (!in_interrupt() &&
  8       (per_cpu(dynticks_progress_counter, cpu) & 0x1) == 0) {
  9     per_cpu(dynticks_progress_counter, cpu)++;
 10     smp_mb();
 11     per_cpu(rcu_update_flag, cpu)++;
 12   }
 13 }

Line 3 fetches the current CPU's number, while lines 4 and 5 increment the rcu_update_flag nesting counter if it is already non-zero. Lines 6 and 7 check to see whether we are the outermost level of interrupt, and, if so, whether dynticks_progress_counter needs to be incremented. If so, line 9 increments dynticks_progress_counter, line 10 executes a memory barrier, and line 11 increments rcu_update_flag. As with rcu_exit_nohz(), the memory barrier ensures that any other CPU that sees the effects of an RCU read-side critical section in the interrupt handler (following the rcu_irq_enter() invocation) will also see the increment of dynticks_progress_counter.

Interrupt entry is handled similarly by rcu_irq_exit():

  1 void rcu_irq_exit(void)
  2 {
  3   int cpu = smp_processor_id();
  4 
  5   if (per_cpu(rcu_update_flag, cpu)) {
  6     if (--per_cpu(rcu_update_flag, cpu))
  7       return;
  8     WARN_ON(in_interrupt());
  9     smp_mb();
 10     per_cpu(dynticks_progress_counter, cpu)++;
 11     WARN_ON(per_cpu(dynticks_progress_counter, cpu) & 0x1);
 12   }
 13 }

Line 3 fetches the current CPU's number, as before. Line 5 checks to see if the rcu_update_flag is non-zero, returning immediately (via falling off the end of the function) if not. Otherwise, lines 6 through 11 come into play. Line 6 decrements rcu_update_flag, returning if the result is not zero. Line 8 verifies that we are indeed leaving the outermost level of nested interrupts, line 9 executes a memory barrier, line 10 increments dynticks_progress_counter, and line 11 verifies that this variable is now even. As with rcu_enter_nohz(), the memory barrier ensures that any other CPU that sees the increment of dynticks_progress_counter will also see the effects of an RCU read-side critical section in the interrupt handler (preceding the rcu_irq_enter() invocation).

These two sections have described how the dynticks_progress_counter variable is maintained during entry to and exit from dynticks-idle mode, both by tasks and by interrupts and NMIs. The following section describes how this variable is used by preemptable RCU's grace-period machinery.

Grace-Period Interface

Of the four preemptable RCU grace-period states shown below (taken from The Design of Preemptable Read-Copy Update), only the rcu_try_flip_waitack_state() and rcu_try_flip_waitmb_state() states need to wait for other CPUs to respond.

Of course, if a given CPU is in dynticks-idle state, we shouldn't wait for it. Therefore, just before entering one of these two states, the preceding state takes a snapshot of each CPU's dynticks_progress_counter variable, placing the snapshot in another per-CPU variable, rcu_dyntick_snapshot. This is accomplished by invoking dyntick_save_progress_counter, shown below:

  1 static void dyntick_save_progress_counter(int cpu)
  2 {
  3   per_cpu(rcu_dyntick_snapshot, cpu) =
  4     per_cpu(dynticks_progress_counter, cpu);
  5 }

The rcu_try_flip_waitack_state() state invokes rcu_try_flip_waitack_needed(), shown below:

  1 static inline int
  2 rcu_try_flip_waitack_needed(int cpu)
  3 {
  4   long curr;
  5   long snap;
  6 
  7   curr = per_cpu(dynticks_progress_counter, cpu);
  8   snap = per_cpu(rcu_dyntick_snapshot, cpu);
  9   smp_mb(); /* force ordering with cpu entering/leaving dynticks. */
 10   if ((curr == snap) && ((curr & 0x1) == 0))
 11     return 0;
 12   if ((curr - snap) > 2 || (snap & 0x1) == 0)
 13     return 0;
 14   return 1;
 15 }

Lines 7 and 8 pick up current and snapshot versions of dynticks_progress_counter, respectively. The memory barrier on line ensures that the counter checks in the later rcu_try_flip_waitzero_state follow the fetches of these counters. Lines 10 and 11 return zero (meaning no communication with the specified CPU is required) if that CPU has remained in dynticks-idle state since the time that the snapshot was taken. Similarly, lines 12 and 13 return zero if that CPU was initially in dynticks-idle state or if it has completely passed through a dynticks-idle state. In both these cases, there is no way that that CPU could have retained the old value of the grace-period counter. If neither of these conditions hold, line 14 returns one, meaning that the CPU needs to explicitly respond.

For its part, the rcu_try_flip_waitmb_state state invokes rcu_try_flip_waitmb_needed(), shown below:

  1 static inline int
  2 rcu_try_flip_waitmb_needed(int cpu)
  3 {
  4   long curr;
  5   long snap;
  6 
  7   curr = per_cpu(dynticks_progress_counter, cpu);
  8   snap = per_cpu(rcu_dyntick_snapshot, cpu);
  9   smp_mb(); /* force ordering with cpu entering/leaving dynticks. */
 10   if ((curr == snap) && ((curr & 0x1) == 0))
 11     return 0;
 12   if (curr != snap)
 13     return 0;
 14   return 1;
 15 }

This is quite similar to rcu_try_flip_waitack_needed, the difference being in lines 12 and 13, because any transition either to or from dynticks-idle state executes the memory barrier needed by the rcu_try_flip_waitmb_state() state.

We now have seen all the code involved in the interface between RCU and the dynticks-idle state. The next section builds up the Promela model used to validate this code.

Validating Preemptable RCU and dynticks

This section develops a Promela model for the interface between dynticks and RCU step by step, with each of the following sections illustrating one step, starting with the process-level code, adding assertions, interrupts, and finally NMIs.

Basic Model

This section translates the process-level dynticks entry/exit code and the grace-period processing into Promela. We start with rcu_exit_nohz() and rcu_enter_nohz() from the 2.6.25-rc4 kernel, placing these in a single Promela process that models exiting and entering dynticks-idle mode in a loop as follows:

  1 proctype dyntick_nohz()
  2 {
  3   byte tmp;
  4   byte i = 0;
  5 
  6   do
  7   :: i >= MAX_DYNTICK_LOOP_NOHZ -> break;
  8   :: i < MAX_DYNTICK_LOOP_NOHZ ->
  9     tmp = dynticks_progress_counter;
 10     atomic {
 11       dynticks_progress_counter = tmp + 1;
 12       assert((dynticks_progress_counter & 1) == 1);
 13     }
 14     tmp = dynticks_progress_counter;
 15     atomic {
 16       dynticks_progress_counter = tmp + 1;
 17       assert((dynticks_progress_counter & 1) == 0);
 18     }
 19     i++;
 20   od;
 21 }

Lines 6 and 20 define a loop. Line 7 exits the loop once the loop counter i has exceeded the limit MAX_DYNTICK_LOOP_NOHZ. Line 8 tells the loop construct to execute lines 9-19 for each pass through the loop. Because the conditionals on lines 7 and 8 are exclusive of each other, the normal Promela random selection of true conditions is disabled. Lines 9 and 11 model rcu_exit_nohz()'s non-atomic increment of dynticks_progress_counter, while line 12 models the WARN_ON(). The atomic construct simply reduces the Promela state space, given that the WARN_ON() is not strictly speaking part of the algorithm. Lines 14-18 similarly models the increment and WARN_ON() for rcu_enter_nohz(). Finally, line 19 increments the loop counter.

Each pass through the loop therefore models a CPU exiting dynticks-idle mode (for example, starting to execute a task), then re-entering dynticks-idle mode (for example, that same task blocking).

The next step is to model the interface to RCU's grace-period processing. For this, we need to model dyntick_save_progress_counter(), rcu_try_flip_waitack_needed(), rcu_try_flip_waitmb_needed(), as well as portions of rcu_try_flip_waitack() and rcu_try_flip_waitmb(), all from the 2.6.25-rc4 kernel. The following grace_period() Promela process models these functions as they would be invoked during a single pass through preemptable RCU's grace-period processing.

  1 proctype grace_period()
  2 {
  3   byte curr;
  4   byte snap;
  5 
  6   atomic {
  7     printf("MAX_DYNTICK_LOOP_NOHZ = %d\n", MAX_DYNTICK_LOOP_NOHZ);
  8     snap = dynticks_progress_counter;
  9   }
 10   do
 11   :: 1 ->
 12     atomic {
 13       curr = dynticks_progress_counter;
 14       if
 15       :: (curr == snap) && ((curr & 1) == 0) ->
 16         break;
 17       :: (curr - snap) > 2 || (snap & 1) == 0 ->
 18         break;
 19       :: 1 -> skip;
 20       fi;
 21     }
 22   od;
 23   snap = dynticks_progress_counter;
 24   do
 25   :: 1 ->
 26     atomic {
 27       curr = dynticks_progress_counter;
 28       if
 29       :: (curr == snap) && ((curr & 1) == 0) ->
 30         break;
 31       :: (curr != snap) ->
 32         break;
 33       :: 1 -> skip;
 34       fi;
 35     }
 36   od;
 37 }

Lines 6-9 print out the loop limit (but only into the .trail file in case of error) and model a line of code from rcu_try_flip_idle() and its call to dyntick_save_progress_counter(), which takes a snapshot of the current CPU's dynticks_progress_counter variable. These two lines are executed atomically to reduce state space.

Lines 10-22 model the relevant code in rcu_try_flip_waitack() and its call to rcu_try_flip_waitack_needed(). This loop is modeling the grace-period state machine waiting for a counter-flip acknowledgment from each CPU, but only that part that interacts with dynticks-idle CPUs.

Line 23 models a line from rcu_try_flip_waitzero() and its call to dyntick_save_progress_counter(), again taking a snapshot of the CPU's dynticks_progress_counter variable.

Finally, lines 24-36 model the relevant code in rcu_try_flip_waitack() and its call to rcu_try_flip_waitack_needed(). This loop is modeling the grace-period state-machine waiting for each CPU to execute a memory barrier, but again only that part that interacts with dynticks-idle CPUs.

The resulting model, when run with the runspin.sh script, generates 691 states and passes without errors, which is not at all surprising given that it completely lacks the assertions that could find failures. The next section therefore adds safety assertions.

Validating Safety

A safe RCU implementation must never permit a grace period to complete before the completion of any RCU readers that started before the start of the grace period. This is modeled by a grace_period_state variable that can take on three states as follows:

  1 #define GP_IDLE    0
  2 #define GP_WAITING  1
  3 #define GP_DONE    2
  4 byte grace_period_state = GP_DONE;

The grace_period() process sets this variable as it progresses through the grace-period phases, as shown below:

  1 proctype grace_period()
  2 {
  3   byte curr;
  4   byte snap;
  5 
  6   grace_period_state = GP_IDLE;
  7   atomic {
  8     printf("MAX_DYNTICK_LOOP_NOHZ = %d\n", MAX_DYNTICK_LOOP_NOHZ);
  9     snap = dynticks_progress_counter;
 10     grace_period_state = GP_WAITING;
 11   }
 12   do
 13   :: 1 ->
 14     atomic {
 15       curr = dynticks_progress_counter;
 16       if
 17       :: (curr == snap) && ((curr & 1) == 0) ->
 18         break;
 19       :: (curr - snap) > 2 || (snap & 1) == 0 ->
 20         break;
 21       :: 1 -> skip;
 22       fi;
 23     }
 24   od;
 25   grace_period_state = GP_DONE;
 26   grace_period_state = GP_IDLE;
 27   atomic {
 28     snap = dynticks_progress_counter;
 29     grace_period_state = GP_WAITING;
 30   }
 31   do
 32   :: 1 ->
 33     atomic {
 34       curr = dynticks_progress_counter;
 35       if
 36       :: (curr == snap) && ((curr & 1) == 0) ->
 37         break;
 38       :: (curr != snap) ->
 39         break;
 40       :: 1 -> skip;
 41       fi;
 42     }
 43   od;
 44   grace_period_state = GP_DONE;
 45 }

Lines 6, 10, 25, 26, 29, and 44 update this variable (combining atomically with algorithmic operations where feasible) to allow the dyntick_nohz() process to validate the basic RCU safety property. The form of this validation is to assert that the value of the grace_period_state variable cannot jump from GP_IDLE to GP_DONE during a time period over which RCU readers could plausibly persist.

The dyntick_nohz() Promela process implements this validation as shown below:

  1 proctype dyntick_nohz()
  2 {
  3   byte tmp;
  4   byte i = 0;
  5   bit old_gp_idle;
  6 
  7   do
  8   :: i >= MAX_DYNTICK_LOOP_NOHZ -> break;
  9   :: i < MAX_DYNTICK_LOOP_NOHZ ->
 10     tmp = dynticks_progress_counter;
 11     atomic {
 12       dynticks_progress_counter = tmp + 1;
 13       old_gp_idle = (grace_period_state == GP_IDLE);
 14       assert((dynticks_progress_counter & 1) == 1);
 15     }
 16     atomic {
 17       tmp = dynticks_progress_counter;
 18       assert(!old_gp_idle || grace_period_state != GP_DONE);
 19     }
 20     atomic {
 21       dynticks_progress_counter = tmp + 1;
 22       assert((dynticks_progress_counter & 1) == 0);
 23     }
 24     i++;
 25   od;
 26 }

Line 13 sets a new old_gp_idle flag if the value of the grace_period_state variable is GP_IDLE at the beginning of task execution, and the assertion at line 18 fires if the grace_period_state variable has advanced to GP_DONE during task execution, which would be illegal given that a single RCU read-side critical section could span the entire intervening time period.

The resulting model, when run with the runspin.sh script, generates 964 states and passes without errors, which is reassuring. That said, although safety is critically important, it is also quite important to avoid indefinitely stalling grace periods. The next section therefore covers validating liveness.

Validating Liveness

Although liveness can be difficult to prove, there is a simple trick that applies here. The first step is to make dyntick_nohz() indicate that it is done via a dyntick_nohz_done variable, as shown on line 26 of the following:

  1 proctype dyntick_nohz()
  2 {
  3   byte tmp;
  4   byte i = 0;
  5   bit old_gp_idle;
  6 
  7   do
  8   :: i >= MAX_DYNTICK_LOOP_NOHZ -> break;
  9   :: i < MAX_DYNTICK_LOOP_NOHZ ->
 10     tmp = dynticks_progress_counter;
 11     atomic {
 12       dynticks_progress_counter = tmp + 1;
 13       old_gp_idle = (grace_period_state == GP_IDLE);
 14       assert((dynticks_progress_counter & 1) == 1);
 15     }
 16     atomic {
 17       tmp = dynticks_progress_counter;
 18       assert(!old_gp_idle || grace_period_state != GP_DONE);
 19     }
 20     atomic {
 21       dynticks_progress_counter = tmp + 1;
 22       assert((dynticks_progress_counter & 1) == 0);
 23     }
 24     i++;
 25   od;
 26   dyntick_nohz_done = 1;
 27 }

With this variable in place, we can add assertions to grace_period() to check for unnecessary blockage as follows:

  1 proctype grace_period()
  2 {
  3   byte curr;
  4   byte snap;
  5   bit shouldexit;
  6 
  7   grace_period_state = GP_IDLE;
  8   atomic {
  9     printf("MAX_DYNTICK_LOOP_NOHZ = %d\n", MAX_DYNTICK_LOOP_NOHZ);
 10     shouldexit = 0;
 11     snap = dynticks_progress_counter;
 12     grace_period_state = GP_WAITING;
 13   }
 14   do
 15   :: 1 ->
 16     atomic {
 17       assert(!shouldexit);
 18       shouldexit = dyntick_nohz_done;
 19       curr = dynticks_progress_counter;
 20       if
 21       :: (curr == snap) && ((curr & 1) == 0) ->
 22         break;
 23       :: (curr - snap) > 2 || (snap & 1) == 0 ->
 24         break;
 25       :: else -> skip;
 26       fi;
 27     }
 28   od;
 29   grace_period_state = GP_DONE;
 30   grace_period_state = GP_IDLE;
 31   atomic {
 32     shouldexit = 0;
 33     snap = dynticks_progress_counter;
 34     grace_period_state = GP_WAITING;
 35   }
 36   do
 37   :: 1 ->
 38     atomic {
 39       assert(!shouldexit);
 40       shouldexit = dyntick_nohz_done;
 41       curr = dynticks_progress_counter;
 42       if
 43       :: (curr == snap) && ((curr & 1) == 0) ->
 44         break;
 45       :: (curr != snap) ->
 46         break;
 47       :: else -> skip;
 48       fi;
 49     }
 50   od;
 51   grace_period_state = GP_DONE;
 52 }

We have added the shouldexit variable on line 5, which we initialize to zero on line 10. Line 17 asserts that shouldexit is not set, while line 18 sets shouldexit to the dyntick_nohz_done variable maintained by dyntick_nohz(). This assertion will therefore trigger if we attempt to take more than one pass through the wait-for-counter-flip-acknowledgment loop after dyntick_nohz() has completed execution. After all, if dyntick_nohz() is done, then there cannot be any more state changes to force us out of the loop, so going through twice in this state means an infinite loop, which in turn means no end to the grace period.

Lines 32, 39, and 40 operate in a similar manner for the second (memory-barrier) loop.

However, running this model results in failure, as line 23 is checking that the wrong variable is even. Upon failure, spin writes out a “trail” file, which records the sequence of states that lead to the failure. Use the spin -t -p -g -l dyntickRCU-base-sl-busted.spin command to cause spin to retrace this sequence of states, printing the statements executed and the values of variables. Note that the line numbers do not match the listing above due to the fact that spin takes both functions in a single file. However, the line numbers do match the full model.

We see that the dyntick_nohz() process completed at step 34 (search for “34:”), but that the grace_period() process nonetheless failed to exit the loop. The value of curr is 6 (see step 35) and that the value of snap is 5 (see step 17). Therefore the first condition on line 21 above does not hold because curr != snap, and the second condition on line 23 does not hold either because snap is odd and because curr is only one greater than snap.

So one of these two conditions has to be incorrect. Referring to the comment block in rcu_try_flip_waitack_needed() for the first condition:

	/*
	 * If the CPU remained in dynticks mode for the entire time
	 * and didn't take any interrupts, NMIs, SMIs, or whatever,
	 * then it cannot be in the middle of an rcu_read_lock(), so
	 * the next rcu_read_lock() it executes must use the new value
	 * of the counter.  So we can safely pretend that this CPU
	 * already acknowledged the counter.
	 */

The first condition does match this, because if curr == snap and if curr is even, then the corresponding CPU has been in dynticks-idle mode the entire time, as required. So let's look at the comment block for the second condition:

	/*
	 * If the CPU passed through or entered a dynticks idle phase with
	 * no active irq handlers, then, as above, we can safely pretend
	 * that this CPU already acknowledged the counter.
	 */

The first part of the condition is correct, because if curr and snap differ by two, there will be at least one even number in between, corresponding to having passed completely through a dynticks-idle phase. However, the second part of the condition corresponds to having started in dynticks-idle mode, not having finished in this mode. We therefore need to be testing curr rather than snap for being an even number.

The corrected C code is as follows:

  1 static inline int
  2 rcu_try_flip_waitack_needed(int cpu)
  3 {
  4   long curr;
  5   long snap;
  6 
  7   curr = per_cpu(dynticks_progress_counter, cpu);
  8   snap = per_cpu(rcu_dyntick_snapshot, cpu);
  9   smp_mb(); /* force ordering with cpu entering/leaving dynticks. */
 10   if ((curr == snap) && ((curr & 0x1) == 0))
 11     return 0;
 12   if ((curr - snap) > 2 || (curr & 0x1) == 0)
 13     return 0;
 14   return 1;
 15 }

Making the corresponding correction in the model results in a correct validation with 661 states that passes without errors. However, it is worth noting that the first version of the liveness validation failed to catch this bug, due to a bug in the liveness validation itself. This liveness-validation bug was located by inserting an infinite loop in the grace_period() process, and noting that the liveness-validation code failed to detect this problem!

We have now successfully validated both safety and liveness conditions, but only for processes running and blocking. We also need to handle interrupts, a task taken up in the next section.

Interrupts

There are a couple of ways to model interrupts in Promela:

1. using C-preprocessor tricks to insert the interrupt handler between each and every statement of the dynticks_nohz() process, or
2. modeling the interrupt handler with a separate process.

A bit of thought indicated that the second approach would have a smaller state space, though it requires that the interrupt handler somehow run atomically with respect to the dynticks_nohz() process, but not with respect to the grace_period() process.

Fortunately, it turns out that Promela permits you to branch out of atomic statements. This trick allows us to have the interrupt handler set a flag, and recode dynticks_nohz() to atomically check this flag and execute only when the flag is not set. This can be accomplished with a C-preprocessor macro that takes a label and a Promela statement as follows:

  1 #define EXECUTE_MAINLINE(label, stmt) \
  2 label: skip; \
  3     atomic { \
  4       if \
  5       :: in_dyntick_irq -> goto label; \
  6       :: else -> stmt; \
  7       fi; \
  8     } \

One might use this macro as follows:

    EXECUTE_MAINLINE(stmt1, tmp = dynticks_progress_counter)

Line 2 of the macro creates the specified statement label. Lines 3-8 are an atomic block that tests the in_dyntick_irq variable, and if this variable is set (indicating that the interrupt handler is active), branches out of the atomic block back to the label. Otherwise, line 6 executes the specified statement. The overall effect is that mainline execution stalls any time an interrupt is active, as required.

Validating Interrupt Handlers

The first step is to convert dyntick_nohz() to EXECUTE_MAINLINE() form, as follows:

  1 proctype dyntick_nohz()
  2 {
  3   byte tmp;
  4   byte i = 0;
  5   bit old_gp_idle;
  6 
  7   do
  8   :: i >= MAX_DYNTICK_LOOP_NOHZ -> break;
  9   :: i < MAX_DYNTICK_LOOP_NOHZ ->
 10     EXECUTE_MAINLINE(stmt1, tmp = dynticks_progress_counter)
 11     EXECUTE_MAINLINE(stmt2,
 12          dynticks_progress_counter = tmp + 1;
 13          old_gp_idle = (grace_period_state == GP_IDLE);
 14          assert((dynticks_progress_counter & 1) == 1))
 15     EXECUTE_MAINLINE(stmt3,
 16       tmp = dynticks_progress_counter;
 17       assert(!old_gp_idle || grace_period_state != GP_DONE))
 18     EXECUTE_MAINLINE(stmt4,
 19       dynticks_progress_counter = tmp + 1;
 20       assert((dynticks_progress_counter & 1) == 0))
 21     i++;
 22   od;
 23   dyntick_nohz_done = 1;
 24 }

It is important to note that when a group of statements is passed to EXECUTE_MAINLINE(), as in lines 11-14, all statements in that group execute atomically.

The next step is to write a dyntick_irq() process to model an interrupt handler:

  1 proctype dyntick_irq()
  2 {
  3   byte tmp;
  4   byte i = 0;
  5   bit old_gp_idle;
  6 
  7   do
  8   :: i >= MAX_DYNTICK_LOOP_IRQ -> break;
  9   :: i < MAX_DYNTICK_LOOP_IRQ ->
 10     in_dyntick_irq = 1;
 11     if
 12     :: rcu_update_flag > 0 ->
 13       tmp = rcu_update_flag;
 14       rcu_update_flag = tmp + 1;
 15     :: else -> skip;
 16     fi;
 17     if
 18     :: !in_interrupt && (dynticks_progress_counter & 1) == 0 ->
 19       tmp = dynticks_progress_counter;
 20       dynticks_progress_counter = tmp + 1;
 21       tmp = rcu_update_flag;
 22       rcu_update_flag = tmp + 1;
 23     :: else -> skip;
 24     fi;
 25     tmp = in_interrupt;
 26     in_interrupt = tmp + 1;
 27     old_gp_idle = (grace_period_state == GP_IDLE);
 28     assert(!old_gp_idle || grace_period_state != GP_DONE);
 29     tmp = in_interrupt;
 30     in_interrupt = tmp - 1;
 31     if
 32     :: rcu_update_flag != 0 ->
 33       tmp = rcu_update_flag;
 34       rcu_update_flag = tmp - 1;
 35       if
 36       :: rcu_update_flag == 0 ->
 37         tmp = dynticks_progress_counter;
 38         dynticks_progress_counter = tmp + 1;
 39       :: else -> skip;
 40       fi;
 41     :: else -> skip;
 42     fi;
 43     atomic {
 44       in_dyntick_irq = 0;
 45       i++;
 46     }
 47   od;
 48   dyntick_irq_done = 1;
 49 }

The loop from line 7-47 models up to MAX_DYNTICK_LOOP_IRQ interrupts, with lines 8 and 9 forming the loop condition and line 45 incrementing the control variable. Line 10 tells dyntick_nohz() that an interrupt handler is running, and line 44 tells dyntick_nohz() that this handler has completed. Line 48 is used for liveness validation, much as is the corresponding line of dyntick_nohz().

Lines 11-24 model rcu_irq_enter(), and lines 25 and 26 model the relevant snippet of __irq_enter(). Lines 27 and 28 validate safety in much the same manner as do the corresponding lines of dynticks_nohz(). Lines 29 and 30 model the relevant snippet of __irq_exit(), and finally lines 31-42 model rcu_irq_exit().

  1 proctype grace_period()
  2 {
  3   byte curr;
  4   byte snap;
  5   bit shouldexit;
  6 
  7   grace_period_state = GP_IDLE;
  8   atomic {
  9     printf("MAX_DYNTICK_LOOP_NOHZ = %d\n", MAX_DYNTICK_LOOP_NOHZ);
 10     printf("MAX_DYNTICK_LOOP_IRQ = %d\n", MAX_DYNTICK_LOOP_IRQ);
 11     shouldexit = 0;
 12     snap = dynticks_progress_counter;
 13     grace_period_state = GP_WAITING;
 14   }
 15   do
 16   :: 1 ->
 17     atomic {
 18       assert(!shouldexit);
 19       shouldexit = dyntick_nohz_done && dyntick_irq_done;
 20       curr = dynticks_progress_counter;
 21       if
 22       :: (curr == snap) && ((curr & 1) == 0) ->
 23         break;
 24       :: (curr - snap) > 2 || (curr & 1) == 0 ->
 25         break;
 26       :: else -> skip;
 27       fi;
 28     }
 29   od;
 30   grace_period_state = GP_DONE;
 31   grace_period_state = GP_IDLE;
 32   atomic {
 33     shouldexit = 0;
 34     snap = dynticks_progress_counter;
 35     grace_period_state = GP_WAITING;
 36   }
 37   do
 38   :: 1 ->
 39     atomic {
 40       assert(!shouldexit);
 41       shouldexit = dyntick_nohz_done && dyntick_irq_done;
 42       curr = dynticks_progress_counter;
 43       if
 44       :: (curr == snap) && ((curr & 1) == 0) ->
 45         break;
 46       :: (curr != snap) ->
 47         break;
 48       :: else -> skip;
 49       fi;
 50     }
 51   od;
 52   grace_period_state = GP_DONE;
 53 }

The implementation of grace_period() is very similar to the earlier one. The only changes are the addition of line 10 to add the new interrupt-count parameter and changes to lines 19 and 41 to add the new dyntick_irq_done variable to the liveness checks.

This model results in a correct validation with roughly half a million states, passing without errors. However, this version of the model does not handle nested interrupts. This topic is taken up in the next section.

Validating Nested Interrupt Handlers

Nested interrupt handlers may be modeled by splitting the body of the loop in dyntick_irq() as follows:

  1 proctype dyntick_irq()
  2 {
  3   byte tmp;
  4   byte i = 0;
  5   byte j = 0;
  6   bit old_gp_idle;
  7   bit outermost;
  8 
  9   do
 10   :: i >= MAX_DYNTICK_LOOP_IRQ && j >= MAX_DYNTICK_LOOP_IRQ -> break;
 11   :: i < MAX_DYNTICK_LOOP_IRQ ->
 12     atomic {
 13       outermost = (in_dyntick_irq == 0);
 14       in_dyntick_irq = 1;
 15     }
 16     if
 17     :: rcu_update_flag > 0 ->
 18       tmp = rcu_update_flag;
 19       rcu_update_flag = tmp + 1;
 20     :: else -> skip;
 21     fi;
 22     if
 23     :: !in_interrupt && (dynticks_progress_counter & 1) == 0 ->
 24       tmp = dynticks_progress_counter;
 25       dynticks_progress_counter = tmp + 1;
 26       tmp = rcu_update_flag;
 27       rcu_update_flag = tmp + 1;
 28     :: else -> skip;
 29     fi;
 30     tmp = in_interrupt;
 31     in_interrupt = tmp + 1;
 32     atomic {
 33       if
 34       :: outermost ->
 35         old_gp_idle = (grace_period_state == GP_IDLE);
 36       :: else -> skip;
 37       fi;
 38     }
 39     i++;
 40   :: j < i ->
 41     atomic {
 42       if
 43       :: j + 1 == i ->
 44         assert(!old_gp_idle ||
 45                grace_period_state != GP_DONE);
 46       :: else -> skip;
 47       fi;
 48     }
 49     tmp = in_interrupt;
 50     in_interrupt = tmp - 1;
 51     if
 52     :: rcu_update_flag != 0 ->
 53       tmp = rcu_update_flag;
 54       rcu_update_flag = tmp - 1;
 55       if
 56       :: rcu_update_flag == 0 ->
 57         tmp = dynticks_progress_counter;
 58         dynticks_progress_counter = tmp + 1;
 59       :: else -> skip;
 60       fi;
 61     :: else -> skip;
 62     fi;
 63     atomic {
 64       j++;
 65       in_dyntick_irq = (i != j);
 66     }
 67   od;
 68   dyntick_irq_done = 1;
 69 }

This is similar to the earlier dynticks_irq() process. It adds a second counter variable j on line 5, so that i counts entries to interrupt handlers and j counts exits. The outermost variable on line 7 helps determine when the grace_period_state variable needs to be sampled for the safety checks. The loop-exit check on line 10 is updated to require that the specified number of interrupt handlers are exited as well as entered, and the increment of i is moved to line 39, which is the end of the interrupt-entry model. Lines 12-15 set the outermost variable to indicate whether this is the outermost of a set of nested interrupts and to set the in_dyntick_irq variable that is used by the dyntick_nohz() process. Lines 32-37 capture the state of the grace_period_state variable, but only when in the outermost interrupt handler.

Line 40 has the do-loop conditional for interrupt-exit modeling: as long as we have exited fewer interrupts than we have entered, it is legal to exit another interrupt. Lines 41-48 check the safety criterion, but only if we are exiting from the outermost interrupt level. Finally, lines 63-66 increment the interrupt-exit count j and, if this is the outermost interrupt level, clears in_dyntick_irq.

This model results in a correct validation with a bit more than half a million states, passing without errors. However, this version of the model does not handle NMIs, which are taken up in the nest section.

Validating NMI Handlers

We take the same general approach for NMIs as we do for interrupts, keeping in mind that NMIs do not nest. This results in a dyntick_nmi() process as follows:

  1 proctype dyntick_nmi()
  2 {
  3   byte tmp;
  4   byte i = 0;
  5   bit old_gp_idle;
  6 
  7   do
  8   :: i >= MAX_DYNTICK_LOOP_NMI -> break;
  9   :: i < MAX_DYNTICK_LOOP_NMI ->
 10     in_dyntick_nmi = 1;
 11     if
 12     :: rcu_update_flag > 0 ->
 13       tmp = rcu_update_flag;
 14       rcu_update_flag = tmp + 1;
 15     :: else -> skip;
 16     fi;
 17     if
 18     :: !in_interrupt && (dynticks_progress_counter & 1) == 0 ->
 19       tmp = dynticks_progress_counter;
 20       dynticks_progress_counter = tmp + 1;
 21       tmp = rcu_update_flag;
 22       rcu_update_flag = tmp + 1;
 23     :: else -> skip;
 24     fi;
 25     tmp = in_interrupt;
 26     in_interrupt = tmp + 1;
 27     old_gp_idle = (grace_period_state == GP_IDLE);
 28     assert(!old_gp_idle || grace_period_state != GP_DONE);
 29     tmp = in_interrupt;
 30     in_interrupt = tmp - 1;
 31     if
 32     :: rcu_update_flag != 0 ->
 33       tmp = rcu_update_flag;
 34       rcu_update_flag = tmp - 1;
 35       if
 36       :: rcu_update_flag == 0 ->
 37         tmp = dynticks_progress_counter;
 38         dynticks_progress_counter = tmp + 1;
 39       :: else -> skip;
 40       fi;
 41     :: else -> skip;
 42     fi;
 43     atomic {
 44       i++;
 45       in_dyntick_nmi = 0;
 46     }
 47   od;
 48   dyntick_nmi_done = 1;
 49 }

Of course, the fact that we have NMIs requires adjustments in the other components. For example, the EXECUTE_MAINLINE() macro now needs to pay attention to the NMI handler (in_dyntick_nmi) as well as the interrupt handler (in_dyntick_irq) by checking the dyntick_nmi_done variable as follows:

  1 #define EXECUTE_MAINLINE(label, stmt) \
  2 label: skip; \
  3     atomic { \
  4       if \
  5       :: in_dyntick_irq || in_dyntick_nmi -> goto label; \
  6       :: else -> stmt; \
  7       fi; \
  8     } \

We will also need to introduce an EXECUTE_IRQ() macro that checks in_dyntick_nmi in order to allow dyntick_irq() to exclude dyntick_nmi():

  1 #define EXECUTE_IRQ(label, stmt) \
  2 label: skip; \
  3     atomic { \
  4       if \
  5       :: in_dyntick_nmi -> goto label; \
  6       :: else -> stmt; \
  7       fi; \
  8     } \

It is further necessary to convert dyntick_irq() to EXECUTE_IRQ() as follows:

  1 proctype dyntick_irq()
  2 {
  3   byte tmp;
  4   byte i = 0;
  5   byte j = 0;
  6   bit old_gp_idle;
  7   bit outermost;
  8 
  9   do
 10   :: i >= MAX_DYNTICK_LOOP_IRQ && j >= MAX_DYNTICK_LOOP_IRQ -> break;
 11   :: i < MAX_DYNTICK_LOOP_IRQ ->
 12     atomic {
 13       outermost = (in_dyntick_irq == 0);
 14       in_dyntick_irq = 1;
 15     }
 16 stmt1: skip;
 17     atomic {
 18       if
 19       :: in_dyntick_nmi -> goto stmt1;
 20       :: !in_dyntick_nmi && rcu_update_flag ->
 21         goto stmt1_then;
 22       :: else -> goto stmt1_else;
 23       fi;
 24     }
 25 stmt1_then: skip;
 26     EXECUTE_IRQ(stmt1_1, tmp = rcu_update_flag)
 27     EXECUTE_IRQ(stmt1_2, rcu_update_flag = tmp + 1)
 28 stmt1_else: skip;
 29 stmt2: skip;  atomic {
 30       if
 31       :: in_dyntick_nmi -> goto stmt2;
 32       :: !in_dyntick_nmi &&
 33          !in_interrupt &&
 34          (dynticks_progress_counter & 1) == 0 ->
 35            goto stmt2_then;
 36       :: else -> goto stmt2_else;
 37       fi;
 38     }
 39 stmt2_then: skip;
 40     EXECUTE_IRQ(stmt2_1, tmp = dynticks_progress_counter)
 41     EXECUTE_IRQ(stmt2_2, dynticks_progress_counter = tmp + 1)
 42     EXECUTE_IRQ(stmt2_3, tmp = rcu_update_flag)
 43     EXECUTE_IRQ(stmt2_4, rcu_update_flag = tmp + 1)
 44 stmt2_else: skip;
 45     EXECUTE_IRQ(stmt3, tmp = in_interrupt)
 46     EXECUTE_IRQ(stmt4, in_interrupt = tmp + 1)
 47 stmt5: skip;
 48     atomic {
 49       if
 50       :: in_dyntick_nmi -> goto stmt4;
 51       :: !in_dyntick_nmi && outermost ->
 52         old_gp_idle = (grace_period_state == GP_IDLE);
 53       :: else -> skip;
 54       fi;
 55     }
 56     i++;
 57   :: j < i ->
 58 stmt6: skip;
 59     atomic {
 60       if
 61       :: in_dyntick_nmi -> goto stmt6;
 62       :: !in_dyntick_nmi && j + 1 == i ->
 63         assert(!old_gp_idle || grace_period_state != GP_DONE);
 64       :: else -> skip;
 65       fi;
 66     }
 67     EXECUTE_IRQ(stmt7, tmp = in_interrupt);
 68     EXECUTE_IRQ(stmt8, in_interrupt = tmp - 1);
 69 
 70 stmt9: skip;
 71     atomic {
 72       if
 73       :: in_dyntick_nmi -> goto stmt9;
 74       :: !in_dyntick_nmi && rcu_update_flag != 0 ->
 75         goto stmt9_then;
 76       :: else -> goto stmt9_else;
 77       fi;
 78     }
 79 stmt9_then: skip;
 80     EXECUTE_IRQ(stmt9_1, tmp = rcu_update_flag)
 81     EXECUTE_IRQ(stmt9_2, rcu_update_flag = tmp - 1)
 82 stmt9_3: skip;
 83     atomic {
 84       if
 85       :: in_dyntick_nmi -> goto stmt9_3;
 86       :: !in_dyntick_nmi && rcu_update_flag == 0 ->
 87         goto stmt9_3_then;
 88       :: else -> goto stmt9_3_else;
 89       fi;
 90     }
 91 stmt9_3_then: skip;
 92     EXECUTE_IRQ(stmt9_3_1, tmp = dynticks_progress_counter)
 93     EXECUTE_IRQ(stmt9_3_2, dynticks_progress_counter = tmp + 1)
 94 stmt9_3_else:
 95 stmt9_else: skip;
 96     atomic {
 97       j++;
 98       in_dyntick_irq = (i != j);
 99     }
100   od;
101   dyntick_irq_done = 1;
102 }

Note that we have open-coded the “if” statements (for example, lines 16-28). In addition, statements that process strictly local state (such as line 56) need not exclude dyntick_nmi().

Finally, grace_period() requires only a few changes:

  1 proctype grace_period()
  2 {
  3   byte curr;
  4   byte snap;
  5   bit shouldexit;
  6 
  7   grace_period_state = GP_IDLE;
  8   atomic {
  9     printf("MAX_DYNTICK_LOOP_NOHZ = %d\n", MAX_DYNTICK_LOOP_NOHZ);
 10     printf("MAX_DYNTICK_LOOP_IRQ = %d\n", MAX_DYNTICK_LOOP_IRQ);
 11     printf("MAX_DYNTICK_LOOP_NMI = %d\n", MAX_DYNTICK_LOOP_NMI);
 12     shouldexit = 0;
 13     snap = dynticks_progress_counter;
 14     grace_period_state = GP_WAITING;
 15   }
 16   do
 17   :: 1 ->
 18     atomic {
 19       assert(!shouldexit);
 20       shouldexit = dyntick_nohz_done &&
 21              dyntick_irq_done &&
 22              dyntick_nmi_done;
 23       curr = dynticks_progress_counter;
 24       if
 25       :: (curr == snap) && ((curr & 1) == 0) ->
 26         break;
 27       :: (curr - snap) > 2 || (curr & 1) == 0 ->
 28         break;
 29       :: else -> skip;
 30       fi;
 31     }
 32   od;
 33   grace_period_state = GP_DONE;
 34   grace_period_state = GP_IDLE;
 35   atomic {
 36     shouldexit = 0;
 37     snap = dynticks_progress_counter;
 38     grace_period_state = GP_WAITING;
 39   }
 40   do
 41   :: 1 ->
 42     atomic {
 43       assert(!shouldexit);
 44       shouldexit = dyntick_nohz_done &&
 45              dyntick_irq_done &&
 46              dyntick_nmi_done;
 47       curr = dynticks_progress_counter;
 48       if
 49       :: (curr == snap) && ((curr & 1) == 0) ->
 50         break;
 51       :: (curr != snap) ->
 52         break;
 53       :: else -> skip;
 54       fi;
 55     }
 56   od;
 57   grace_period_state = GP_DONE;
 58 }

We have added the printf() for the new MAX_DYNTICK_LOOP_NMI parameter on line 11 and added dyntick_nmi_done to the shouldexit assignments on lines 22 and 46.

The model results in a correct validation with several hundred million states, passing without errors.

Conclusions

This effort provided some lessons (re)learned:

Promela and spin can validate interrupt/NMI-handler interactions.

Documenting code can help locate bugs. In this case, the documentation effort located this bug.

Validate your code early, often, and up to the point of destruction. This effort located one subtle bug that might have been quite difficult to test or debug.

Always validate your validation code. The usual way to do this is to insert a deliberate bug and verify that the validation code catches it. Of course, if the validation code fails to catch this bug, you may also need to verify the bug itself, and so on, recursing infinitely. However, if you find yourself in this position, getting a good night's sleep can be an extremely effective debugging technique.

Finally, if cmpxchg instructions ever become inexpensive enough to tolerate them in the interrupt fastpath, their use could greatly simplify this code. The Promela model for an atomic-instruction-based implementation of this code has more than an order of magnitude fewer states, and the C code is much easier to understand. On the other hand, one must take care when using cmpxchg instructions, as some code sequences, if highly contended, can result in starvation. This situation is particularly likely to occur when part of the algorithm uses cmpxchg, other parts of the algorithm use atomic instructions that cannot fail (e.g., atomic increment), contention for the variable in question is high, and the code is running on a NUMA or a shared-cache machine. Sadly, almost all multi-socket systems with either multi-core or multi-threaded CPUs fit this description.

Acknowledgments

We are indebted to Andrew Theurer, who maintains the large-memory machine that ran the full test. We all owe a debt of gratitude to Vara Prasad for his help in rendering this article human-readable.

Technical requests can usually be taken care of with compromises and options at build-time, so a solution will usually be found in time. Philosophical needs, on the other hand, often put distributions and original developers on two opposite positions, and cannot be fixed unless one of the two accepts the position of the other.

While technical needs are usually shared between distributions, different distributions have different goals, and in turn different philosophical needs, and this adds to the problem. A project wanting to accommodate the requests from a distribution might make life more difficult for another, that has different philosophical issues.

User expectations

Users of a distribution usually expect a certain behaviour from the software they install. For graphical applications, they also might expect a certain graphical aspect so that all the applications blend in together. These problems may be easier to solve as non-technical concerns go, as they usually require providing more choices.

One common example comes with fonts in graphical environments: most distributions these days ship with all the graphical applications set to use the same font family. This is done to follow the style rule of using as few different fonts in a single view as possible (you don't usually see a book using ten or twelve different fonts in the text). So one common request is for software to provide a way to change the default font without user intervention (which otherwise often involves changing the source code).

This still seems to be a technical issue; for example, using TrueType fonts requires the use of some sophisticated libraries for font rendering. Some projects don't want to complicate their code with them. Similarly, some distributions like to provide anti-aliasing for the default fonts, but some projects dislike the whole idea of using anti-aliased fonts.

A similar issue might arise with GUI toolkits. Distributions tend to provide the same graphical aspect for the software they install, this usually means that both GTK+ and Qt are set to a similar, if not identical, themes. So one other thing distributions might like is for graphical software to rely on a theme-capable toolkit. Themes and skin, though, are often disliked by minor projects, which might also not be using GTK+ or Qt toolkits, as they tend to make the code more complex and slow.

Users expect to be able to set their language preference and to have all applications use that language. Unfortunately adding support for translations is a far from trivial task, and adds complexity to the software, which is something that especially smaller software projects try to avoid. Similar complexity stems also from supporting text encoding like UTF-8, which - for certain distributions like Fedora - is a prerequisite for the software to be added to their repository.

It's easy to see that user requests are often pretty complex and hard to implement on many existing projects. The best way to make a project more appealing for distributions is to start from the beginning with these points in mind.

Distribution philosophical policies

There are also distribution policies regarding issues that are simply philosophical. In this category you can find the requests of distributions for removing code that deals with non-free formats, like most multimedia formats. All these issues are usually centered around licensing, copyright and patent-encumbered formats or algorithms:

• Multimedia formats, video, audio or picture formats are often considered patent-encumbered (sometimes with the exception of Xiph formats like Ogg, Vorbis and Theora). Most distributions would like support for these to always be optional, for this reason. This might actually start to be a problem for multimedia applications as their main goal is just to provide support for these patent-encumbered formats.
• Usage of GPL-incompatible libraries by GPL applications, and other forms of licenses mixing is a quite big issue for almost all binary distributions. Some distributions will not be able to legally redistribute packages with licensing issues. This is why distributions often push for optional support for GnuTLS as a replacement for OpenSSL, or build packages without SSL support by default. (In addition to license problems, SSL support is also encumbered with special cryptography legislation, which makes its handling even more a problem).
• In both multimedia and cryptography there is the problem of patent-encumbered algorithms. Even when the format itself is not encumbered, the algorithm used to generate the result might be. Distributions want a way to opt-out some of the support in the software.
• Support for network analysis tools can also be a problem. While the boundary between analysis and cracking can be quite thin, laws like the ones enacted in Germany start making it difficult for distributions to carry tools that are even well inside the definition of network analysis rather than network cracking.

For some distributions, there are extra policies that depend on the license used by the project itself. For instance if they disallow changes to the source (verbatim copy only) they might disallow the distribution from taking the proper steps to fix technical issues.

Each distribution has its philosophical goals, such as a focus on Free Software or a focus on corporate users. These goals will influence the distribution's view of philosophical issues. Companies tend to take a more defensive look at these issues than community projects. European projects tend to be more lax when it comes to software patent problems, and other countries don't enforce copyright laws. These are the types of factors that will affect a distribution's philosophical goals.

Conclusions

The issues described in this section can also conflict directly with the goals of the upstream project (and they often do), in which case the project is very unlikely to be packaged officially by at least some distributions.

This is why I categorized these issues under the philosophical name rather than technical. It's actually fairly common that issues of this kind sprout debates inside and outside projects and distributions, as developers and maintainers have very different feelings about them.

One example is a software package in which the team is composed entirely by native English speakers. Such a project has a fair chance to start without considering that some users might expect the user interface to be available in any other language. While this might sound a bit harsh, it's often true.

It is nearly impossible for a project to satisfy these issues altogether for every possible distribution. And it becomes even harder when the project itself focuses on keeping the code as simple as possible, even when that means ignoring features and optimizations that require adding complexity.

For this reason, the issues listed here have to be taken as suggestions, rather than requirements, depending on the original goals for the project. If the project wants to be widely accepted though, it will need to provide a good mitigation method for these issues.

Afterword

In addition to these issues, that relate directly with the source and the software, there are some extra suggestions that can be given to make the whole project friendlier to distributors, entailing process and workflow changes.

Making it visible in the source code who and where to send patches and suggestions is certainly a nice initial step. When preparing a patch for software that misbehaves, it's usually simpler to read the documentation shipped with the software. Distribution developers are less likely to open a browser to check the homepage of the software, looking for the address to use. This also means that you should always make sure to update your address referenced in the software documentation. If you change your email address, and the old one is no longer reachable, it is a good idea to re-roll the tarball even if no code changes are present (in these cases, adding a suffix to the tarball is better than changing the version).

Even better, having a public way to track patches is often useful: distributions can easily see if someone else fixed that issue before, and how. It might save a downstream maintainer some work, and it helps having a solution that works for more than one person at a time.

Acknowledging the patches, and pointing out what is not going to work, is something that helps reduce the frustration for maintainers, as it allows them to better suit the coding style of the project each time. Ignoring a patch entirely is not a good idea, as these patches are rarely non-issues.

It's also important to notice that almost always the patches don't concern optimizations. Most distributions are generally less concerned with the performance of the software over the correctness as defined by their own policies. Distributions would often prefer to reduce the speed of the software if that makes it better follow their policy. This has also to be understood and accepted, and at the best worked around by either improving the optimization, allowing an option, or by making a trade off.

Having a public repository for the source is often helpful, but often not in major ways. While it makes it easier for the downstream maintainers to check the progress of the code, it might not be trivial to identify where the correct source is. If the project uses branches it might well be that the upstream developers have already moved away from the broken code by the time a distribution tries to package it. If a repository is available, regular tagging and branching is helpful, and makes it easier for a maintainer to find what has actually changed between two or more versions.

Finally

This article cannot cover all the possible requests that a distribution might have, and it does not even get close to all the possible requests by all possible distributions. There are even more requests relating to portability, for distributions that target particular non-mainstream hardware (e.g. distributions targeting embedded device like OpenWRT) or distributions for other (Free and non-Free) operating systems (like Cygwin, Fink or FreeBSD ports). The remaining issues have to be coped with on an incremental basis, with collaboration of the downstream maintainers for that distribution.

Following these practices might make it easier for those people to contact the upstream developers to work out a solution. They make the project appear friendlier, just as well as saying Please let us know how we can improve your users' experience with our software. They change the mindset of a project so that it makes it less frustrating for packagers to prepare it for distributions. Going against all these points not only makes the job harder for the distributors, but might give the (wrong) idea that the project is not open to accommodating distributions.

Comments (1 posted)

Number 9, number 9. Fedora 9 Preview has been cleared for takeoff!

A preview release of Fedora 9 is now available. "For this Preview release, we will be doing a staged offering. The first stage, available now, will be via bittorrent. The second stage, which should be available early next week, will be via our world wide mirroring system, and will include jigdo." The final GOLD Fedora 9 release is expected on May 13th. Update: Direct download and jigdo download options are now available for Fedora 9 Preview. Please see this page for details.

Full Story (comments: 34)

openSUSE 11.0 Beta 1 released

The first beta release for openSUSE 11.0 is out. "There are many exciting enhancements and features in the new release. Among these is the incredibly fast package management (libzypp), KDE 3.5.9 and 4.0.3, GNOME 2.22.1, a beautiful new installer, installable live CDs and much more."

Full Story (comments: none)

New Version of RedHawk Linux Offers Increased Real-Time Functionality and Performance

Concurrent has announced that it has released a new version of the RedHawk Linux real-time operating system. RedHawk Linux 5.1 can be used in time-critical applications in simulation and training, data acquisition, imaging, financial services and process control. RedHawk guarantees that a user-level application can respond to an external event in less than 30 microseconds.

Full Story (comments: none)

Slackware 12.1 RC2

The April 21st entry in the Slackware-current changelog says: "We have now reached the Slackware 12.1 RC2 milestone. :-) We're beyond updating packages or fixing minor cosmetic bugs at this point (actually, we had hoped to be past that with RC1, but there were still items in need of attention). What we have here now has proven to be stable for our testers, so unless some real showstoppers are found we'll be releasing this as Slackware 12.1-final soon.". Click below for this snippet of the changelog, or view the complete changelog.

Full Story (comments: 6)

Announcing the Release Candidate for Ubuntu 8.04 LTS

The Ubuntu team has announced the Release Candidate for Ubuntu 8.04 LTS (Long-Term Support) on desktop and server. The Ubuntu 8.04 LTS family of variants, Kubuntu, Xubuntu, UbuntuStudio, and Mythbuntu, have also reached RC status. The final release of Ubuntu 8.04 LTS is scheduled for 24 April 2008 and will be supported for three years on the desktop and five years on the server.

Full Story (comments: none)

Ubuntu 8.04 LTS server and desktop releases

Ubuntu 8.04 LTS, the Hardy Heron, is scheduled for release on Thursday, April 24, 2008. In anticipation, Canonical has issued a pair of press releases for the server and the desktop editions.

"Ubuntu 8.04 Long Term Support (LTS) Server Edition adds new features to enhance the performance, stability and security of this fully supported general platform. The LTS release sees further expansion of the commercial ecosystem of software, hardware and services vendors supporting Ubuntu Server."

"Ubuntu 8.04 Long Term Support (LTS) provides a stable platform for software and hardware vendors, developers and users. With three years of support and maintenance on the desktop, 8.04 LTS is a great choice for large-scale deployment. A substantial and growing ecosystem of free and commercial software built for Ubuntu provides a rich set of choices for desktop users. This is the eighth desktop release of Ubuntu. Ubuntu's track record in delivering - on a precise schedule every six months - a commercial operating system that is free, stable, secure and fully supported, remains unique."

Comments (28 posted)

Vyatta Community Edition 4 Scales from Branch Office to Data Center

Vyatta has announced Vyatta Community Edition 4 (VC4), the latest release of its reliable, commercially supported open-source network operating system. "VC4 delivers significant scalability improvements and expanded application support to its router/firewall/VPN feature set and achieves a 10X price/performance advantage over proprietary network solutions."

Comments (none posted)

Bits from the DPL: FTP-master & DAM delegations

Sam Hocevar, the current Debian Project Leader, has appointed Joerg Jaspert as FTP-master and a full Debian Account Manager. Joerg is therefore empowered to create and remove developer accounts according to the New Maintainer procedure.

Full Story (comments: none)

Bits from the DPL: marketing team delegations

Sam Hocevar has appointed Andreas Schuldei and Moritz Muehlenhoff to the Debian marketing team. "I like to think of the marketing team as a non-technical equivalent to the technical committee, with a looser organisation. Its goal is to improve Debian's visibility and attractiveness amongst users and contributors, both actual and prospective."

Full Story (comments: none)

Bits from the New DPL

Steve McIntyre, the newly elected Debian Project Leader, shares some of his plans for the coming year. "The first thing I've promised to work on is a review of all the core jobs in Debian. There are plainly places where we can improve on how things are working, and my very first task is going to be looking into those."

Full Story (comments: none)

Summary: Extremadura meetings 2007

Three Debian work meetings were held last year in Extremadura, Spain. Click below for a summary of the meetings with Debian Edu, the QA, VoIP and Zope teams and the Qt/KDE and i18n teams.

Full Story (comments: none)

Fedora goes to a community-dominated board

Fedora project leader Paul Frields has announced a change in the way the Fedora board is elected; as of the upcoming election, five of the nine seats will be elected by the community, while four will be appointed by Red Hat. So Red Hat will no longer select a majority of the board. "This is an issue I've been advocating over the past couple of weeks, and I'm delighted to be able to make this change following my first release as Fedora Project Leader. I look at this as a significant step in the evolution of the Board and Fedora's governance overall." It's worth noting that the Fedora leader (who must still be a Red Hat employee) retains veto power over board decisions.

Full Story (comments: 8)

Fedora Board Recap 2008-APR-15

Click below for a recap of the April 15, 2008 meeting of the Fedora board, which looks at spins, board succession, and Codeina.

Full Story (comments: none)

Fedora 9 Xfce Spin - Progress Report, Update

Rahul Sundaram takes a look at the Fedora 9 Xfce spin. "One of the major reasons I kept the package list small in Fedora 8 was to retain even the x86_64 image under CD size. Since the default multi-lib policy has changed in yum now to not install both 32-bit and 64-bit libs, I have added more useful (hopefully) packages. The total size in x86 arch is 608 MB and additional 20 MB or so for x86_64. I haven't tried it under PPC. Any testing there would be very welcome."

Full Story (comments: 1)

Fedora 9 Release date slipping by two weeks

The Fedora project has announced that the release date for Fedora 9 will be delayed until May 13. "This slip is not intended to make room for more changes, it is only intended to make room for fixing the things we already know about, and allowing new things to be found, and evaluated as release blocking, and fixed. There are also a fair number of bugs we think we've already fixed, but need wider audience testing to be sure."

Full Story (comments: 12)

SPARC architecture moved to ports.ubuntu.com for 8.04 and beyond

The Ubuntu SPARC architecture has moved. If you use this port you should update your /etc/apt/sources.list file to get future updates. Click below for more information.

Full Story (comments: none)

Have Ubuntu your way: 64 Studio Ltd. announces new custom distribution services

64 Studio Ltd. has announced that its Debian customization platform has been extended to support Ubuntu sources. This means that the company can now produce, maintain and support one-off distributions which retain package compatibility with official Ubuntu releases. "64 Studio offers OEMs and system integrators an automated platform which takes the labour out of distribution maintenance and back-porting. The company also offers day to day developer and end user support for the custom distributions it produces, including documentation services. Customer applications and branding are integrated into both daily install image builds and fully managed APT servers, allowing users to keep their systems up to date easily. Builds can be optimised for 64-bit x86 CPUs, low energy consumption 32-bit hardware, or legacy systems."

Full Story (comments: none)

Webconverger

Webconverger uses Debian Live technology to provide a Web platform for kiosks, thin clients, or anywhere else you want a secure, dedicated web browser. It runs from a live CD or USB device. A hard drive install option will probably be available in the future. The maxi version of Webconverger has good support for CJK languages, such as Korean. Webconverger 3 beta with Firefox 3 beta is available for download.

Comments (none posted)

Ubuntu Weekly Newsletter #87

The Ubuntu Weekly Newsletter for April 19, 2008 covers Ubuntu 8.04 LTS Release Candidate, Release Candidate Testing, Ubuntu Open Week, Abiword 2.6 needs testers, ShipIt 8.04 CD orders, Hardy Heron release parties, FISL (5th International Free Software Forum) in Brazil, Ubuntu Desktop training, Ubuntu ported to ARM, and much more.

Full Story (comments: none)

pure:dyne news

Pure:dyne is a community effort maintained by media artists for media artists. This newsletter covers the 'pure:dyne for everyone' program, the upcoming pure:dyne public events, pure:dyne code sprints in 2008, a new, Debian based pure:dyne! Click below to find out more.

Full Story (comments: none)

openSUSE Weekly News, Issue 18

This edition of the openSUSE Weekly News covers openSUSE Project Releases Major Update to openSUSE Build Service, Counting down to 11.0 - Get your counter here!, LugRadio Live (so far), Tips and Tricks: Colored shell, Stephan Kulow: openSUSE 11.0: Package installation 743% faster for default patterns, and more.

Comments (none posted)

DistroWatch Weekly, Issue 249

The DistroWatch Weekly for April 21, 2008 is out. "It's that time of the year when the fans of Ubuntu rejoice over another new release, while those jealous of the project's growing success on the desktop would rather stay away from the Internet. But Ubuntu is not the only option; although delayed by two weeks, Fedora 9 will arrive in a blink of an eye, while openSUSE 11.0, one of the most technologically advanced distribution releases the Linux world has ever seen, is also making huge strides towards the planned release date in June. In other news, Red Hat and OpenSolaris take different views of the alternative desktop, Mark Shuttleworth opens a discussion over the future of Gobuntu and gNewSense, Mandriva introduces a new urpmi feature for adding third-party repositories, and sidux announces the release of sidux-seminarix, a Debian-based distribution for schools. Finally, don't miss our feature story: a first look at Draco GNU/Linux, an unusual distribution that combines Slackware's base system and NetBSD's packages into a powerful desktop Linux solution."

Comments (none posted)

Debian Project News debuts

The first issue of Debian Project News (DPN) is out, with coverage of the new Debian Project Leader, an update on the release status, Debian participation in the Google Summer of Code, and much more. DPN is the successor to Debian Weekly News and will be a bi-weekly publication. Click below for the edition.

Full Story (comments: 3)

Ubuntu Live 2008 Takes Ubuntu Further

Registration is open for Ubuntu Live 2008. The conference is scheduled for July 21 and 22, 2008, at the Oregon Convention Center in Portland, Oregon. Canonical Ltd. and O'Reilly Media copresent this conference, which happens concurrently with the O'Reilly Open Source Convention 2008 at the same venue.

Full Story (comments: none)

Gentoo Council member speaks with LinuxCrazy

Gentoo council member Mike Frysinger talked to David Abbott of LinuxCrazy. You can download the podcast or read the transcript. "David Abbott: What is the most fun about being a Gentoo developer? Mike Frysinger: As Gentoo users, we tend to learn a lot. Even as a developer, you learn about how everything fits together and how all the low layer pieces work. There really isn't any more magic anymore. You really learn it all. And the other aspect is working with all the other people. There are so many other Gentoo developers that are smarter than I am. They are great to work with. It's so much fun."

Comments (none posted)

First Look at Fedora 9 Preview (Red Devil's Tech Blog)

Red Devil takes Fedora 9 Preview for a test drive. "I'VE spent a few of days in the company of Fedora 9 Preview and my first impressions are very favourable. Installed into an 8GB Virtualbox virtual machine, it's a snappy release with a high degree of consistency and stability throughout. A lot of the hard work has been done on background stuff - those items mentioned in my 'Big Stuff' list below. But that's not to ignore the importance of visual appeal, where Fedora 9 scores very highly too. Anyway, here's my early impressions and a few screenshots to whet your appetites."

Comments (none posted)

5 Reasons Why You'll Love Fedora 9 (JonRob's Weblog)

Jonathan Roberts looks forward to the final Fedora 9 release. "One significant feature that has appeared in this release that has come from active Fedora developer Alexander Larsson is the improved file management abilities provided by GVFS, allowing the queuing of file transfers and increased resilience to failures. Also new in GNOME for Fedora 9 is integration of support for the X RandR extension: this allows a user to do many things, including drag and drop configuration of multi-head monitor set-ups. This particular feature landed too late to make it upstream for the 2.22 release, but it will be included in the next up-stream release."

Comments (none posted)

Firebird adds new features with version 2.1

Firebird is one of the popular open-source relational database management systems (RDBMS) that runs under Linux. From the about Firebird document:

Stable version 2.1 of Firebird was announced on April 18, 2008: "Firebird 2.1 is a full version release that builds on the architectural changes introduced in the V.2.0 series. Thanks to all who have field-tested the Alphas and Betas during 2007 and the first quarter of 2008 we have a release that is bright with new features and improvements, including the long-awaited global temporary tables, a catalogue of new run-time monitoring mechanisms, database triggers and the injection of dozens of internal functions into the SQL language set."

A summary of new features from the release announcement includes:

• Database triggers for making user-defined triggers have been added.
• Global temporary tables are now available for the handling of non-persistent data.
• New common table expressions are available for making dynamic recursive queries.
• An optional RETURNING clause which supports update, insert and delete operations has been added.
• The MERGE function now has an UPDATE OR INSERT statement for performing conditional operations.
• The new LIST() function can retrieve information in the form of a comma-separated list.
• New built-in functions have been added to replace UDF library calls.
• Text BLOBs up to 32K in length can now masquerade as varchars.
• Procedural SQL (PSQL) local variables can now be declared using domains.
• PSQL variables and arguments can be COLLATEd.
• A new DDL CREATE COLLATION command has been added, replacing the need for a script.
• New Unicode collations can be applied to any character set.
• The ability to perform run-time database snapshot monitoring via SQL has been added.
• The performance of the remote protocol has been improved to better support operation on slow networks.

More details on the version 2.1 release are available in the release notes [PDF]. The document should be read by those who are upgrading from older versions of Firebird. The release notes list a number of additional changes, including:

• The reworking of the on disk structure (ODS).
• Improvements to the PSQL error stack trace.
• The availability of more context information.
• A new fbsvcmgr command-line interface to the Services API.
• Support for named cursors.
• Implementation of the new XNET local transport protocol.
• A rework of the garbage collection mechanism.
• The Services API to Classic architecture port has been finished.
• Lock timeouts are now available for WAIT transactions.
• New Database Shutdown Modes have been added.
• The NULL handling for UDFs has been improved.
• There have been synchronization logic improvements.
• Support has been added for 64 bit platforms.
• Larger record enumeration limits are now supported.
• Debugging improvements have been added.
• Connection handling on the POSIX superserver has been improved.
• The PSQL invariant tracking system has been reworked.
• The ROLLBACK RETAIN clause is now supported.
• There have been improvements made to the optimizer routines.
• Numerous Windows improvements have been added.

Clearly, the Firebird developers have been busy working on this software. If the above lists aren't enough, the Firebird home page notes that there is a mechanism for users to request more new features. The development roadmap for 2008 gives an idea of where the project is headed. Several bug fix releases are scheduled for version 2.1 in the near future and work on the next major release, version 2.5, is already in progress. Firebird is available for download here.

Comments (5 posted)

Assimilator: announcing the 1.1 release (SourceForge)

Version 1.1 of Assimilator has been announced. "Assimilator is a set of tools and services providing a self-monitoring, self-managing and self-healing environment for distributed computing. Assimilator 1.1 has been posted. It contains bug fixes, JMX support, drag and drop of oar files onto the console, and various cleanup work."

Comments (none posted)

PostgreSQL Weekly News

The April 20, 2008 edition of the Postgres Weekly News is online with the latest PostgreSQL DBMS articles and resources.

Full Story (comments: none)

SQLite release 3.5.8 announced

Version 3.5.8 of SQLite, a light weight DBMS, has been announced. "Changes associated with this release include the following: Expose SQLite's internal pseudo-random number generator (PRNG) via the sqlite3_randomness() interface New interface sqlite3_context_db_handle() that returns the database connection handle that has invoked an application-defined SQL function. New interface sqlite3_limit() allows size and length limits to be set on a per-connection basis and at run-time. Improved crash-robustness: write the database page size into the rollback journal header. Allow the VACUUM command to change the page size of a database file..."

Comments (none posted)

BusyBox 1.10.1 announced

Stable version 1.10.1 of BusyBox, a collection of command line utilities for embedded systems, has been announced: "Bugfix-only release for 1.10.x branch. It contains fixes for fuser, init, less, nameif, tail, taskset, tcpudp, top, udhcp."

Comments (none posted)

Cooperative Linux: v0.7.3 (rc3) release candidate available (SourceForge)

Version 0.7.3 rc3 of Cooperative Linux has been announced. "Cooperative Linux is the first method for optimally running Linux on Windows and other operating systems natively. It is a port of the Linux kernel and support code that allows it to run cooperatively without emulation along with another operating system".

Comments (none posted)

mod_perl 2.0.4 announced

Version 2.0.4 of mod_perl, the Perl language interface to the Apache web server, has been announced. "frankie_guasch writes "Finally, it's here and it works with Perl 5.10!"

Comments (none posted)

SBLIM: New Release - sfcb 1.3.0 (SourceForge)

Version 1.3.0 of SBLIM has been announced. "SBLIM (pronounced "sublime"), the Standards Based Linux Instrumentation for Manageability is an IBM-initiated Open Source project, intended to enhance the manageability of GNU/Linux systems. It does so by enabling WBEM, Web Based Enterprise Management. A new major release of sfcb, 1.3.0, is now available from our SourceForge download page. Along with many bugfixes, there are several new features".

Comments (none posted)

SIMPL: v3.2.0 released (SourceForge)

Version 3.2.0 of SIMPL has been announced. "Send/Receive/Reply messaging, popularized in commericial RTOS's such as QNX, is intuitive and simple to understand and an immensely powerful way of designing distributed software applications. This project aims to bring these tools to Linux. This release adds the RS232 surrogate to the mix. It also changes the default header format for TCP/IP intersurrogate communications to text format in anticipation of fully obsoleting binary (byte order dependent) format in future releases."

Comments (none posted)

Renoise 1.9.1 "GOLD" released

Version 1.9.1 of Renoise has been announced. "Renoise is a contemporary digital audio workstation (DAW) based upon the heritage and development of tracker software. Its primary use is the composition of music using samples (in WAV, AIFF, FLAC, Ogg, and MP3 format), and MIDI sequencing of VSTi soft synths. Changes: With input from a very enthusiastic user community, two and a half months were spent on bug fixes and stability improvements for the Linux beta. The work has paid off and the Linux version is now officially 1.9.1 "GOLD" like it's OS X and Windows counterparts."

Full Story (comments: none)

JSynoptic: V2.4.2 delivery (SourceForge)

Version 2.4.2 of JSynoptic has been announced, it adds several new capabilities "JSynoptic renders information graphically. It can be used as a simple graph plotter, or as a complex run-time monitoring environment. The user sets up shapes (like plots) on graphical pages, and uses data sources (ex: ASCII file) to render information."

Comments (none posted)

GNOME 2.23.1 released

Version 2.23.1 of the GNOME desktop environment has been announced. "Welcome to the 2.23 development cycle! This is the first release in our trip to GNOME 2.24, which will be out in September, in around five months. We'll hopefully enjoy some nice new bugs and crashes, while we'll have to live with new features, improvements or fixes. To be honest, I was a bit sad when I smoketested this release because I was expecting to see way more problems. I didn't even see a single crash."

Full Story (comments: none)

GNOME Software Announcements

The following new GNOME software has been announced this week:

• Accerciser 1.3.1 (new features and translation work)
• Beagle 0.3.6 (new features, bug fixes and translation work)
• cheese 2.23.1 (bug fixes and translation work)
• Clutter Cairo 0.6.1 (feature backport)
• Dasher 4.9.0 (new features)
• Deskbar-Applet 2.23.1 (new features, bug fixes and translation work)
• Empathy 0.23.1 (new features, bug fixes and translation work)
• Eye of GNOME 2.23.1 (new features, bug fixes and translation work)
• gbacklight 0.1 (initial release)
• Gcalctool 5.23.1 (bug fixes)
• Glade 3.4.4 (bug fixes and translation work)
• Glade 3.4.5 (bug fix)
• GLib 2.9.3 (new features, bug fixes and translation work)
• glibmm 2.16.2 (bug fixes and documentation work)
• gnome-control-center 2.23.1 (bug fixes and translation work)
• gnome-games 2.23.1 (new features, bug fixes and translation work)
• gnome-media 2.23.1.1 (new features, bug fixes and translation work)
• GNOME Session 2.23.1 (new code base and translation work)
• gnome-settings-daemon 2.23.1 (new features, bug fixes and translation work)
• gnome-speech 0.4.19 (bug fixes)
• gnubiff 2.2.10 (bug fixes and translation work)
• goobox 2.0.0 (new features, bug fixes and translation work)
• JSON-GLib 0.5.0 (new features and bug fixes)
• JSON-GLib 0.6.0 (new features, bug fixes and documentation work)
• mousetweaks 2.23.1 (new features, bug fixes and translation work)
• Orca 2.23.1 (bug fixes and translation work)
• Pango-1.21.0 (new features and bug fixes)
• Pessulus 2.23.1 (new features, bug fixes and translation work)
• Planner 0.14.3 (new features and bug fixes)
• Swfdec 0.6.6 (bug fixes)
• Tinymail pre-release v0.0.9 (new features and bug fixes)
• Vala 0.3.1 (new features and bug fixes)
• Zenity 2.23.1 (bug fixes and translation work)

You can find more new GNOME software releases at gnomefiles.org.

Comments (none posted)

KDE Commit-Digest (KDE.News)

The April 13, 2008 edition of the KDE Commit-Digest has been announced. The content summary says: "Complete source rewrite, with many improvements, in KInfoCenter. Important work on the "Quick Launch", "Folder View", and "RSSNOW" Plasma applets. Initial work towards future support for a list of timezones tooltip for the digital-clock Plasmoid. KMoon is obsoleted by the Plasma "Luna" applet. "Ozone", a fork of the Oxygen window decoration style which respects system colour preferences. Get Hot New Stuff support for icon themes in KDE. KNotify notifications interface now conforms to the Galago specification..."

Comments (none posted)

KDE Software Announcements

The following new KDE software has been announced this week:

• eggy 0.2.1 (new features and bug fixes)
• KLinkStatus 0.5.0 (new features)
• K Menu Gnome 0.7.2 (code improvements)
• Kommander 1.3.1 (new features)
• KPoGre 1.6.4 (new features and bug fixes)
• KRadioRipper 0.2.0 (code improvements)
• KShowmail 3.2.1 (bug fixes)
• KShowmail 3.3 (new features)
• KTorrent 2.2.6 (bug fixes)
• KuFTP 1.5.0 (unspecified)
• KVolumeOSD 0.1 (initial release)
• MaK changer 0.3.63 (new features)
• Yakuake 2.9.2 (bug fix and Qt 4.4 support)

You can find more new KDE software releases at kde-apps.org.

Comments (none posted)

Scribus 1.3.3.11 released

Version 1.3.3.11 of Scribus, a desktop publishing system, has been announced. "This stable release adds the following: Several fixes and improvements to text frames and the Story Editor. New Arabic Translation. More translation and documentation updates. Many improvements to PDF Forms exporting and non-Latin script handling in PDFs. Several fixes to protect against possible crashes. Improved Color Managed Display in some cases. Some fixes to the Scripting plugin."

Comments (none posted)

Ember 0.5.2 released

Version 0.5.2 of Ember has been announced by the WorldForge virtual world project, it includes new capabilities and bug fixes. "Ember version 0.5.2 has been released and is now available from the WorldForge download site. Ember is a 3d client for the WorldForge project. It uses the Ogre 3d graphics library for presentation and CEGUI for its GUI system."

Comments (none posted)

Wine 0.9.60 released

Version 0.9.60 of Wine has been announced. Changes include: Improved support for the .NET framework, Better services handling through a separate services.exe process, Support for ATI fragment shader, Better support for http proxies, Window management fixes, Pre-compiled fonts are now available in the source tree and Lots of bug fixes.

Comments (none posted)

Claws Mail 3.4.0 released

Version 3.4.0 of Claws Mail has been announced. "New in this release: Added support for /dev/mem_notify. This Linux kernel feature will allow applications to be notified that memory has to be freed before getting OOM-killed. For more information: http://lwn.net/Articles/267013/. Enabled moving/copying folders to root folders when using the folder selection dialogue. Global and per-folder templates can now override the From name. Added a tooltip with extended folder stats. (Hover the cursor over the short stats on the right, below the message list.)..."

Comments (none posted)

The initial release of ladosc

The first release of ladosc has been announced. "ladosc is a set of ladspa plugins for composing music with Linux."

Full Story (comments: none)

Strasheela 0.9.5 released

Version 0.9.5 of the Strasheela music composition system has been announced. "This release enhances Strasheela's capabilities for outputting microtonal music into sound synthesis formats such as Csound or MIDI. The actual playback pitch of notes can be defined by tuning tables, which are similar to the scale format of Scala".

Full Story (comments: none)

Security vulnerabilities fixed in OpenOffice.org 2.4

Version 2.4 of OpenOffice.org has been announced. "Please note that OpenOffice.org version 2.4, released on 27th March, fixed a number of security vulnerabilities. To our knowledge, none of these has been exploited; however, in accordance with industry best practice, we recommend all users upgrade to 2.4. This information has been withheld until now to ensure that all the products derived from the OpenOffice.org codebase have been able to include these security fixes before the public announcement of the vulnerabilities."

Full Story (comments: none)

eSpeak 1.37 announced

Version 1.37 of the eSpeak speech synthesis program has been announced. From the ChangeLog file: "Added build options for pulseaudio and sada sound systems. Bug fixes: Fixed crash on some very long words. Fixed crash when saying "ligature A E". Added support for mbrola Spanish voices es1, es2. Fixed letter names lang=it 'v' 'x'"

Comments (none posted)

Ubuntuzilla: 4.4.6 released. (SourceForge)

Version 4.4.6 of Ubuntuzilla has been announced. "Ubuntuzilla is a python script that allows the user to install the latest versions of Mozilla Firefox, Mozilla SeaMonkey, and Mozilla Thunderbird on Ubuntu Linux, with minimal disturbance to the system. This version has a fix to make it work properly on Ubuntu 8.04 (Hardy), and a couple minor enhancements."

Comments (none posted)

GCC 4.3.1 status report (2008-04-17)

The GCC 4.3.1 status report for April 17, 2008 has been published. "GCC 4.3.1 is due around 2008-05-05. As soon as the P1 bugs are fixed and we have -mcld workaround for the x86 direction flag issue, we'll release 4.3.1-rc1. One of the 4 P1s has approved patch and one has been failing also in 4.1/4.2, so IMHO we could release 4.3.1 even without it being fixed. But the remaining two, PR35758 and PR35773, are new C++ 4.3/4.4 regressions and is something that really should be fixed before 4.3.1."

Full Story (comments: none)

Caml Weekly News

The April 22, 2008 edition of the Caml Weekly News is out with new articles about the Caml language.

Full Story (comments: none)

GJDoc 0.7.9 released

Version 0.7.9 of GJDoc has been announced. "gjdoc is the GNU documentation generation framework for java source files. This release is mainly to make sure that gjdoc can generate documentation for the latest version of GNU Classpath (0.97.1). The support for the 1.5 language features isn't complete, but this release of gjdoc should be able to at least handle the basics and generate documentation for java source code files that contain generics, annotations and enumerations."

Full Story (comments: none)

OpenXava: 3.0.1 released (SourceForge)

Version 3.0.1 of OpenXava has been announced. "OpenXava is a framework to develop Java Enterprise/J2EE applications rapidly and easily. Allows you to define applications just with POJOs, JPA and Java 5 annotations. Feature rich and flexible since it's used for years to create business applications with Java."

Comments (none posted)

SBCL 1.0.16 has been released

Version 1.0.16 of Steel Bank Common Lisp has been announced. "This version improves introspection of instances, adds support for fcntl file locks, optimizes special variable binding, speeds up MEMBER, ASSOC, and LOGNOT, and fixes many bugs."

Full Story (comments: none)

What's new in Zend Framework V1.5 (developerWorks)

The Zend framework for PHP is popular for developing applications in that language. developerWorks has an article covering the most recent Zend framework release, v1.5. "Zend stands out by putting a huge emphasis on best practices, which appeals to those of you who value sustainability. Zend also makes a point of constructing the framework in a remarkably modular fashion: Most of the individual Zend Framework components can be pulled completely out and used on their own, which appeals to developers who only need a fraction of the available libraries. Zend's flexibility, combined with the solid standardization that comes with emphasizing best practices, makes it a practical framework for a broad spectrum of purposes."

Comments (none posted)

Python-URL! - weekly Python news and links

The April 21, 2008 edition of the Python-URL! is online with a new collection of Python article links.

Full Story (comments: none)

Tcl-URL! - weekly Tcl news and links

The April 17, 2008 edition of the Tcl-URL! is online with new Tcl/Tk articles and resources.

Full Story (comments: none)

GIT 1.5.5.1 announced

Version 1.5.5.1 of the GIT distributed version control system has been announced. "Fortunately there weren't many brown paper bag breakages we needed to fix immediately after releasing 1.5.5, but there do exist some usability and documentation fixes accumulated on the maintenance branch."

Full Story (comments: none)

Low-cost laptop program sees a key leadership defection (AP)

Here's an AP article about Walter Bender's departure from OLPC with a number of discouraging statements. "One current hang-up is whether the necessary hardware would add $7 to $12 to an XO's cost, taking the project even further away from its eventual goal of producing the machines for less than $100. Eventually, Negroponte added, Windows might be the sole operating system, and Sugar would be educational software running on top of it."

Comments (31 posted)

AMD/ATi release Catalyst 8.4, adds support for new cards under Linux (ZDNet)

Adrian Kingsley-Hughes writes about the release of the Catalyst 8.4 video driver suite in a ZDNet blog. "There more good news for Linux users. Catalyst 8.4 introduces support for the Radeon HD 3800 series (but not the Radeon HD 3870 X2 … yet), Radeon HD 3600 series, and the Radeon HD 3400 series. Also, these drivers add support for Ubuntu 8.04."

Comments (none posted)

Curl debuts its RIA features for Ubuntu Linux (ComputerWorld)

ComputerWorld reports on Curl's new support for Ubuntu. "Curl Inc. today announced support for Ubuntu Linux, which will allow desktop Ubuntu users to easily see Curl-enhanced Web content on their computers without having to manually configure a player. The rich Internet application (RIA) vendor said the Ubuntu Installer for its Curl 6.0 platform also provides tools for Web developers to create rich Internet content that will be viewable to Ubuntu users." The software is available for free download, but is commercially licensed.

Comments (1 posted)

Microsoft, Novell To Sell Linux Licenses In China (InformationWeek)

InformationWeek takes a look at an extension of the Novell-Microsoft pact into Chinese markets. Both want to convert unsupported Linux users into supported users of SUSE Linux. "Mirroring the companies' partnership in the West, Microsoft will buy certificates for SUSE Linux service and support from Novell and resell them to its Chinese customers. Microsoft and Novell also said they plan to host a series of roundtable discussions with corporate chief information officers in Shenzhen, Guangzhou, Shanghai, and Beijing to promote the program."

Comments (3 posted)

Reliability: Unix and Linux beat Windows (heise online)

Heise online looks at a Yankee Group report on server reliability. "Yankee Group market researchers have presented the results of a study on server and operation system reliability for 2007. Compared to the previous year, annual downtime on all systems has dropped sharply – except on Windows server 2000 and 2003. With between one and two hours of downtime per year, enterprise versions of Linux all performed at a similar level; at some five hours downtime, Debian was the poorest performer. Windows Server 2000 and 2003 had downtimes of ten and nine hours per year, respectively (99.9 per cent accessibility)."

Comments (24 posted)

Japan KDE Users Group Interview (KDE.News)

KDE.News has an interview with Daisuke Kameda of the Japanese KDE Users Group. "How did the Japanese KDE Users Group start? It had its beginning when Junji Takagi made a patch for operating multibyte characters such as Japanese, when Qt's version 1.x was released. Qt 1.x couldn't operate mulitibyte characters, so we couldn't use Japanese in KDE 1.x previously. After the patch was made, The Japan KDE Users' Group was launched for aggregating the information about KDE/Qt in Japan."

Comments (none posted)

Benchmarking Linux filesystems on software RAID 1 (Lone Wolves)

The Lone Wolves weblog has a report on benchmarking Linux filesystems using software RAID. "As it turns out, my (then) limited understanding of RAID and some trouble with my 3ware RAID cards meant that I had to scale back my benchmark quite a bit. I only have two disks so I was going to test RAID 1. Chunk size is not a factor when using RAID 1 so that axis was dropped from my benchmark. Then I found out that LVM (and the size of the extends it uses) are also not a factor, so I dropped another axis. And to top it off I discovered some nasty problems with 3ware 9550 RAID cards under Linux that quickly made me give up on hardware RAID."

Comments (21 posted)

NLnet supports KOffice (KDE.News)

KDE.News has announced new support for KOffice by NLnet. "The Dutch NLnet foundation aims to financially support organisations and people that contribute to an open information society. Some time ago they decided to help KOffice in two exciting ways: to sponsor the design of a new logo for KOffice, with matching logo designs for all KOffice applications, and to sponsor Girish Ramakrishnan to improve the ODF support in KWord 2.0. The KOffice team is deeply grateful to NLnet for this support!"

Comments (none posted)

Walter Bender's "goodbye OLPC" note

Walter Bender, former president of the One Laptop Per Child project, has left that position - the latest of many to leave that project. Click below for the note he sent to the community on the way out. "After more than two years without a break at One Laptop per Child, I have decided to take some time to reflect on how I can best contribute going forward to the goal of giving children around the world opportunities for a quality learning experience."

Full Story (comments: 25)

OSI announces board election results

The Open Source Initiative has announced the results of their board elections, somewhat belatedly. Martin Michlmayr and Harshad Gune, the two nominees of the OSI board, were elected unanimously, though Bruce Perens was nominated based on his write-in campaign for a seat. Some additional analysis can be found at the 451 CAOS Theory weblog.

Comments (7 posted)

Audacity is mentoring five Google Summer of Code students

The Audacity audio editor project has announced its support for five Google Summer of Code students. "Audacity has been approved to mentor five students for Google Summer of Code 2008! GSoC offers student developers $4,500 stipends to write code for various open source projects."

Comments (none posted)

XMMS2 Google Summer of Code students accepted

The XMMS2 music player project has announced the allocation of six GSoC students. "Google was kind enough to allocate 6 (yes six!) slots to XMMS2 for this year's Summer of Code. We received many high quality applications and the selection was harder than ever. The selected projects are all very exciting and span all over the xmms2 codebase..."

Comments (none posted)

CodeWeavers announces experimental builds of CrossOver

CodeWeavers has announced experimental builds of their CrossOver interoperability product. "I am happy to announce that we are now making available 'cutting edge' builds of CrossOver. To start, we are providing experimental builds of CrossOver Games for Linux, Mac OS X, and now BSD systems. We remain committed to providing our customers with a stable, and reliable product; one that has been tested thoroughly. So even though we are the major driving force behind Wine, CrossOver always lags behind Wine so that we can do careful development and testing."

Full Story (comments: none)

Frictional Games releases Penumbra: Black Plague

Frictional Games has announced the release of the game Penumbra: Black Plague for Linux and Mac OSX. "Penumbra is a first person adventure game which focuses on story, immersion and puzzles. Instead of using violence to progress the player has to use his/her wits to guide Philip on his quest to unravel the past. Played from a first person viewpoint, Penumbra is very different from other adventure games. Not only is it powered by a 3D engine utilising cutting edge technology, it also has an advanced physics system which allow for a never before seen environment interaction."

Full Story (comments: 1)

O'Reilly launches InPractice

O'Reilly has announced the launch of O'Reilly InPractice. "This new consulting and training division aims to help companies intelligently and successfully reposition themselves in the global network--and thrive in a user-centered economy. "We created O'Reilly InPractice to assist companies that are serious about applying Web 2.0 principles but don't know how or where to start," said Tim O'Reilly, founder and CEO of O'Reilly Media. "The experts at O'Reilly InPractice draw on the wealth of our experience to create a practical path for companies to make the transition to Web 2.0 and the Social Web.""

Full Story (comments: none)

Red Hat: no desktop products coming

Red Hat's desktop team has posted an item saying that the company has no plans to offer a "traditional desktop product" anytime soon. "An explanation: as a public, for-profit company, Red Hat must create products and technologies with an eye on the bottom line, and with desktops this is much harder to do than with servers. The desktop market suffers from having one dominant vendor, and some people still perceive that today's Linux desktops simply don't provide a practical alternative. Of course, a growing number of technically savvy users and companies have discovered that today's Linux desktop is indeed a practical alternative. Nevertheless, building a sustainable business around the Linux desktop is tough, and history is littered with example efforts that have either failed outright, are stalled or are run as charities." The article goes on to list a number of desktop-oriented things that Red Hat is working on.

Comments (77 posted)

Sun and Wind River to deliver carrier grade Linux on UltraSPARC T2

Sun Microsystems and Wind River have announced an effort to port the Carrier Grade Linux and Workbench development suite to the UltraSPARC T2 processor. "Wind River Platform for Network Equipment, Linux Edition, will be the first carrier grade Linux for Sun's CMT processors. With this announcement, Sun and Wind River will be providing the networking industry with a fully integrated, optimized and tested solution of the industry's leading multicore processing hardware and CGL, enabling companies to quickly develop and deploy next-generation enabled networking applications."

Full Story (comments: none)

Trusted Computer Solutions introduces Security Blanket Enterprise Edition

Trusted Computer Solutions, Inc. has announced the general availability of Security Blanket 2.0 Enterprise Edition, an automated system lock down and security management tool for Linux operating systems. "This enterprise solution enables systems administrators to automatically configure and enhance the security of their Linux operating platforms by simplifying the "hardening" process that must be undertaken on a regular basis to meet security compliance requirements."

Full Story (comments: none)

Zenoss closes record quarter

Zenoss has announced a record quarter. "Zenoss Inc., a leading provider of open source network and systems management software, propelled by explosive customer growth has expanded their operations to Austin, Texas through the addition of a new software development center. The Austin development team collectively comprises over fifty years of experience bringing enterprise-class systems management software to market."

Full Story (comments: none)

Perl 6 Design Minutes for 16 April 2008

The April 16, 2008 Perl 6 Design Minutes have been posted. "The Perl 6 design team met by phone on 16 April 2008. Larry, Allison, Jerry, Will, Nicholas, Jesse, and chromatic attended."

Comments (none posted)

DeepSec Conference call for papers

A call for papers has gone out for the DeepSec Conference. The event will take place in Vienna, Austria on November 11-14, 2008. The submission deadline is July 15. "We are interested in bleeding edge security research directly from leading researchers, professionals, academics, industry, government and the underground security community. Please do not submit specific single exp[l]oits (which might be fixed by the time of the conference) and "yet-another-PHP-hack" or the like. Exploit frameworks, general approaches, "defective by design" resp. "defective by implementation" and high impact exploits have a much higher chance ;)"

Full Story (comments: none)

FreedomHEC 2008 announced

FreedomHEC 2008 has been announced. "FreedomHEC 2008, the Linux device driver "unconference", will take place November 8-9, 2008 in Santa Monica, California, following WinHEC in Los Angeles. Plan to attend and learn why Linux support has become an industry standard requirement for new hardware, and how you can get your products supported under Linux quickly and conveniently for customers."

Full Story (comments: none)

GUADEMY 2008: Final program and online participation

The final program for GUADEMY 2008 has been published, along with a notice of online participation. "To enable participation of all people in GUADEMY 2008, we are going to broadcast the event through video streaming, and we have configured a Jabber room as a return channel for enable the online participation in the discussions."

Full Story (comments: none)

2009 GUADEC and Akademy to be co-hosted - maybe

The GNOME and KDE projects have sent out a call for proposals to host both GUADEC and Akademy at the same time and place in 2009. "This would be the first time that the conferences are to be co-hosted. The combined conference is expected to have around 800 attendees, being one of the biggest meetings of free software developers in the world. The content of the conferences will be organized independently, with a number of co-ordinated cross-over sessions with appeal to all attendees." They are hedging their bets, though, and not promising that the combined conference will happen.

Comments (none posted)

Education Day at Maker Faire

The Maker Faire will have a new Education Day. "Sebastopol, CA-Friday, May 2nd, Maker Faire will host its first-ever Education Day, a special day of programming allowing students and teachers to meet and interact with some of this year's Makers. Celebrating things people create themselves-from electronic gizmos to renewable energy and homemade food and clothes, Maker Faire, put on by Make Magazine and Craft Magazine, is the world's premier event for DIY (Do It Yourself) creativity."

Full Story (comments: none)

Announcing the monotone Developer Summit

The monotone Developer Summit will take place in Wuppertal, Germany on April 28 - May 4, 2008. "Beside the usual Meet & Greet the main topic will be of course undisturbed hacking, either on monotone's sources or a monotone-related project, like TracMonotone (Python, Trac) or guitone (C++, Qt4)."

Full Story (comments: none)

RailsConf 2008 registration opened

RailsConf 2008 registration is open. "Registration has opened for RailsConf 2008, scheduled for May 29 through June 1 at the Oregon Convention Center in Portland, Oregon. Copresenters Ruby Central and O'Reilly Media have announced the program, which combines keynotes, sessions, tutorials, panels, and events in an interactive meeting ground for the innovative Rails experts and companies. The conference provides attendees with examples of successful business models, development paradigms, and design strategies to enable mainstream businesses new to the Web and Rails to take advantage of this new generation of services and opportunities. "

Full Story (comments: none)

Rockbox Euro Devcon 2008

The Rockbox Euro Devcon will be held in Berlin, Germany on June 28-29, 2008.

Full Story (comments: none)

Call for Hosts for Akademy 2009 (KDE.News)

A call for hosts has gone out for Akademy 2009. "Preparations for Akademy 2008 are in full swing, but KDE e.V. is already looking forward to next year and asks potential hosts to submit proposals for Akademy 2009. For the first time we also invite proposals to hold Akademy and GUADEC, the GNOME community conference, in the same location."

Comments (none posted)

Events: May 1, 2008 to June 30, 2008

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
April 27 May 2	INTEROP Las Vegas 2008	Las Vegas, NV, USA
April 28 May 4	Monotone Developer Summit	Wuppertal, Germany
May 2 May 3	Maker Faire Bay Area	San Mateo, CA, USA
May 5 May 9	Ruby on Rails Bootcamp with Charles B. Quinn	Atlanta, Georgia, USA
May 8	Embedded Masterclass 2008	London, UK
May 8 May 11	Libre Graphics Meeting 2008	Wroclaw, Poland
May 8 May 9	IV WHYFLOSS CONFERENCE MADRID 08	Madrid, Spain
May 9 May 11	Pycon Italia Due	Firenze, Italy
May 12 May 14	Where 2.0 Conference	Burlingame, CA, USA
May 13	Embedded Masterclass 2008	Bristol, UK
May 15	NLUUG spring conference 2008	Ede, the Netherlands
May 15 May 16	YAPC::Asia 2008	Tokyo, Japan
May 15 May 16	V WHYFLOSS CONFERENCE CORRIENTES 08	Corrientes, Argentina
May 16 May 17	FOSSCamp 2008	Prague, Czech Republic
May 17 May 18	4th Int. Workshop on Software Engineering for Secure Systems (SESS'08)	Leipzig, Germany
May 17 May 18	French-speaking Python Days	Paris, France
May 19 May 23	AFS and Kerberos Best Practices Workshop 2008	Newark, NJ, USA
May 20 May 23	PGCon 2008	Ottawa, Ontario, Canada
May 20 May 21	Digital Standards Organization (Digistan) Workshop	The Hague, The Netherlands
May 21 May 22	EUSecWest 2008	London, England
May 21 May 22	linuxdays.ch Genève	Genève, Switzerland
May 28 May 31	LinuxTag 2008 where .com meets .org	Berlin, Germany
May 29 June 1	RailsConf 2008	Portland, OR, USA
May 29 May 30	SyScan’08 Hong Kong	Hong Kong, China
May 30 May 31	eLiberatica 2008 - The benefits of Open and Free Technologies	Bucharest, Romania
June 2 June 5	VON.x Europe	Amsterdam, the Netherlands
June 3 June 4	Nordic Nagios Meet	Stockholm, Sweden
June 6 June 7	Portuguese Perl Workshop	Braga, Portugal
June 6 June 7	European Tcl/Tk User Meeting 2008	Strasbourg, France
June 9 June 13	Python Bootcamp with David Beazley	Atlanta, Georgia, USA
June 10 June 15	REcon 2008	Montreal, Quebec, Canada
June 11 June 13	kvm developer's forum 2008	Napa, CA, USA
June 16 June 18	YAPC::NA 2008	Chicago, IL, USA
June 17 June 22	Liverpool Open Source City	Liverpool, England
June 18 June 20	Red Hat Summit 2008	Boston, MA, USA
June 18 June 20	National Computer and Information Security Conference ACIS 2008	Bogota, Columbia
June 19 June 21	Fedora Users and Developers Conference	Boston, MA, USA
June 22 June 27	2008 USENIX Annual Technical Conference	Boston, MA, USA
June 23 June 24	O'Reilly Velocity Conference	San Francisco, CA, USA
June 28 June 29	Rockbox Euro Devcon 2008	Berlin, Germany

If your event does not appear here, please tell us about it.