User: Password:
Subscribe / Log in / New account

Kernel development

Brief items

Kernel release status

The current development kernel is 3.1-rc8, released on September 27. "The diffstat is pretty tiny, with some coretemp and clock_ops patches standing out, along with a small perf-tool update and everything else being pretty much one- or few-liners. And not that many of those either." The actual 3.1 release may not happen yet for a week or so due to the issues, but otherwise this kernel appears to be close to ready.

3.1-rc7 came out on September 21, several microseconds after the LWN weekly edition was published. Linus said:

It is becoming clear that I might as well not release the final 3.1 until after my upcoming vacation early October - otherwise the next merge window would just be total chaos. A merge window with being off just really wouldn't work, and doing a release only to then have some chaotic merge window followed by travel seems crazy.

Among other things, that implies that the next merge window may overlap with the Kernel Summit, which could involve some craziness of its own.

Stable updates: no stable updates have been released in the last week.

Comments (none posted)

Quotes of the week

Since I've sent already a RFC about it, I am sending now a RFD. If you eager for meaning, this can then be a "Request for Doctors", since Peter [Zijlstra] is likely to have a heart attack now.
-- Glauber Costa

Here is an example of a PGA (Pin Grid Array) chip seen from underneath:

        A   B   C   D   E   F   G   H
   8  | o | o   o   o   o   o   o   o
      |   |
   7  | o | o   o   o   o   o   o   o
      |   |
   6  | o | o   o   o   o   o   o   o
   5  | o | o | o   o   o   o   o   o
      +---+---+               +---+
   4    o   o   o   o   o   o | o | o
                              |   |
   3    o   o   o   o   o   o | o | o
                              |   |
   2    o   o   o   o   o   o | o | o
   1  | o   o | o   o | o   o | o | o |

This is not tetris. The game to think of is chess.
-- Linus Walleij's pinmux pawns

We invested a year trying to be good Linux citizens, laying out our initial plans, following the rules, working transparently, folding in feedback, submitting hundreds of patches in plain sight of everyone and now folks are asking about our plan. Our plan is get the brcmsmac and brcmfmac into mainline and keep following that up with new features, new chips and continuing support.
-- Brett Rudley

Comments (1 posted)

A status update

The developers working on putting back together have sent out a brief status update, mostly about the management of git trees. "This new infrastructure will no longer have shell access to the git repositories; instead we will be running git using the gitolite web glue. Gitolite uses ssh keys to push into it, so we will start sending out new ssh credentials to the active developers who had accounts before." Git trees should go back online in the near future; everything else will take longer.

Full Story (comments: 75)

Kernel development news

The forest on the move

By Jonathan Corbet
September 28, 2011
As of this writing, remains offline, though it is to be hoped that access for git trees, at least, will be restored before too long. Linus's current plans seem to involve opening the merge window before mid-October; without a functioning, that will not run anywhere near as smoothly as the community might like. Still, some things cannot be rushed, and it is important that come back in a solid and secure mode.

Quite a few trees have found new homes in the mean time. Here is an updated version of the list of relocated trees:

ALSA drivergit://
ALSA SOCgit://
amd64 EDACgit://
mmcgit:// mmc-next

That is a substantial list of moved trees, but, as linux-next maintainer Stephen Rothwell noted on September 27, that leaves 89 trees which still only exist on Those trees will not have seen any updates since went off the net. Some of them will certainly be trees that are currently idle or close to it; not every tree feeding into linux-next carries patches for every development cycle. But others presumably exist for a reason; if does not come back soon, they will need to find a different home.

One significant tree that has not moved is the stable release tree; the last stable updates came out on August 29.

With luck, will come back soon and the above list will become moot. But, when it returns, may look somewhat different. It has already been announced that there will be no shell access to the machines hosting the git trees. There may be other security measures put into place as well, some possibly requiring changes in how developers operate. Making changes of that nature in the time left before the next merge window could be hard to do. The 3.2 development cycle, in other words, might be a bit more interesting and less smooth than usual.

Comments (7 posted)

A look at the 3.1 development cycle

By Jonathan Corbet
September 28, 2011
As of this writing, the final 3.1 release is probably about one week or so away. That is just a bit later than had been expected; it is, of course, a natural result of the extended outage at At a little past 3.1-rc7, though, this kernel is complete enough for our traditional look at what happened during the development cycle. At 8,465 non-merge changesets, the 3.1 cycle is one of the slowest of recent times, but we had participation from about the usual number of developers (1,136) representing over 180 companies. The kernel grew by just over 125,000 lines this time around.

The most active developers in the 3.1 cycle were:

Most active 3.1 developers
By changesets
Takashi Iwai1401.7%
Mark Brown1371.6%
Mauro Carvalho Chehab1271.5%
Roland Vossen1081.3%
Russell King1061.3%
Al Viro1051.2%
Arend van Spriel1051.2%
Joe Perches931.1%
Rafał Miłecki871.0%
Alan Cox851.0%
Axel Lin800.9%
Christoph Hellwig780.9%
Jon Medhurst750.9%
Ben Skeggs680.8%
Neil Brown680.8%
Wey-Yi Guy660.8%
Kuninori Morimoto650.8%
David S. Miller630.7%
Shawn Guo610.7%
Jonathan Cameron590.7%
By changed lines
Greg Kroah-Hartman12151214.8%
Ralph Metzler260433.2%
Takashi Iwai249193.0%
Vladislav Zolotarov241092.9%
Nicholas Bellinger228252.8%
Roland Vossen204722.5%
Alan Cox204292.5%
Oliver Endriss194722.4%
matt mooney168042.0%
Krishna Gudipati159201.9%
Arend van Spriel156591.9%
Chaoming Li153191.9%
Dominik Brodowski152511.9%
Mauro Carvalho Chehab129741.6%
Jonas Bonn111121.4%
Mark Brown108201.3%
Kamil Debski93111.1%
Andy Grover67530.8%
Yaniv Rosner65260.8%
Joe Perches65020.8%

Media drivers would appear to dominate the listings on the "by changesets" side. Takashi Iwai continues to be incredibly productive in the area of audio drivers; Mark Brown, too, works mostly in the audio area. Mauro Carvalho Chehab is the Video4Linux2 maintainer; all of his patches fall within that tree this time around. Roland Vossen, instead, contributed a large number of changes to the Broadcom wireless network driver. Russell King not only serves as the top-level ARM maintainer; he also made a number of changes in that tree this time.

Greg Kroah-Hartman has, once again, been the top changer of lines in the kernel. Once again, the bulk of his work is in the staging tree; this time, though, he got there by deleting a number of drivers that either were not going to make it into the mainline or were on their way out. Ralph Metzler only contributed five patches, but three of them added new drivers to the Video4Linux2 tree. Takashi Iwai shows at the top of both columns for his sound driver work, Vladislav Zolotarov contributed a single patch with a bunch of new Broadcom firmware, and Nicholas Bellinger continues to enhance the SCSI target code.

Of the 182 employers identified as contributing to the 3.1 kernel, the most active were:

Most active 3.0 employers
By changesets
Red Hat88210.4%
Texas Instruments2763.3%
Wolfson Microelectronics1421.7%
Renesas Electronics1001.2%
By lines changed
Red Hat582627.1%
Metzler Brothers Systementwicklung GbR236812.9%
Rising Tide Systems230902.8%
Texas Instruments211302.6%
Realsil Microelectronics158681.9%
Wolfson Microelectronics140041.7%
South Pole AB120871.5%

Broadcom's extensive work to move its wireless driver out of staging caused it to move to a higher than usual position on both lists. Also notable is the continued slow climb by companies like Texas Instruments and Samsung; Nokia, instead, appears to be about to fall out of the top 20. The handling of Linaro deserves an explanation: contributions by Linaro assignees is normally credited back to their home companies. Nonetheless, Linaro makes an appearance on its own here as the result of the work of an increasing number of engineers employed by the organization itself.

Finally, here is a plot showing the number of changesets merged for each stabilization release (those after -rc1) for the last few development cycles:


The dark blue line represents the 3.1 development cycle; as might be expected, the number of changesets merged drops significantly after 3.1-rc4, which is when the outage started. Both 3.1-rc5 and 3.1-rc6 were smaller than usual releases, but 3.1-rc7 has made up for some of the slowdown. It would appear that the subsystem maintainers affected by the outage have mostly managed to find new places to host their trees. The kernel development show manages to go on, even with the loss of its primary repository hosting site.

Comments (none posted)

A new approach to opportunistic suspend

By Jonathan Corbet
September 27, 2011
"Opportunistic suspend" is the power management technique used by Android devices. Rather than trying to put the various system components into a low-power state, opportunistic suspend works by simply suspending the entire device whenever it is determined that nothing interesting is going on. Managing power consumption in this way is controversial, but the real problem has to do with the determination that it is a good time to suspend. Android's mechanism for controlling opportunistic suspend has been called "wakelocks" or "suspend blockers"; either way, it has had a bumpy ride whenever attempts have been made to merge it into the mainline. John Stultz has just proposed an alternative to suspend blockers that is guaranteed an equally bumpy ride, but it is interesting to look at regardless.

Suspend blockers are a way for either the kernel or user space to tell the system that it is not a good time to suspend; the use of suspend blockers from user space is a privileged operation. To work properly, suspend blockers must be supported by any device that can wake up the system. Drivers for such devices will, when a wakeup event occurs, acquire a suspend blocker and wake any user-space process waiting on the event; once that process reads the event, the suspend blocker will be released. The key is that said user space process, if it is sufficiently privileged, can acquire a suspend blocker of its own before reading the event that woke it up. The overlap between the acquisition of the user-space blocker and the release of the kernel-space blocker allows for reliable system wakeups without the risk of suspending before a wakeup event has been processed.

One of the things John didn't like about this mechanism was the implicit suspend blocker API between user space and wakeup-capable devices. So he has come up with something a bit different, even if the core idea is quite similar.

The whole point of suspend blockers is to allow "important" processes to keep the device awake even if it would otherwise choose to suspend itself. So, John asked, why not just mark the important processes as such? His patch adds a new scheduler option:

    sched_setscheduler(0, SCHED_STAYAWAKE, &param);

Any time that a process has been marked in this way, the kernel simply will not suspend the system. That is true even if the given process blocks; otherwise, a disk I/O operation or page fault would be enough to put the system into an untimely sleep.

Of course, life is not quite so simple; there are times when it is desirable to suspend the system even with "important" processes on it. One of those is whenever the important process blocks on a device that is capable of generating wakeup events. Enabling suspend at such times requires tweaking the relevant drivers; in essence, a line like:


must be added to remove the blocking process's "important" status just before putting it to sleep. When that device wakes the blocked process, its special status will be returned to it.

The only remaining problem is, once again, keeping the system from re-suspending before the important process gets its status back. That is handled by placing calls to __pm_stay_awake() and __pm_relax() around the code that wakes blocked processes. John also had to change the suspend code to make __pm_stay_awake() a bit less advisory than it is in current kernels. With that in place, the device will not suspend before any important processes have had the chance to reclaim their status.

As of this writing, the only feedback on the patch set has come from scheduler maintainer Peter Zijlstra. Suffice to say he didn't like it. According to Peter, opportunistic suspend is an attempt to paper over a problem that should be solved in user space; unimportant processes, he says, simply should not be running in the first place. That view, in turn, is unlikely to be popular in the Android camp. So, even though John's approach simplifies the wakelock idea, it does not seem likely to put an end to the debate over that approach to power management.

Comments (21 posted)

Patches and updates

Kernel trees


Core kernel code

Development tools

Device drivers


Filesystems and block I/O

Memory management


Page editor: Jonathan Corbet
Next page: Distributions>>

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