The current development kernel is 3.1-rc8
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.
actual 3.1 release may not happen yet for a week or so due to the
kernel.org 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
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 kernel.org 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
Comments (none posted)
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)
The developers working on putting kernel.org 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 kernel.org accounts
" Git trees should go back online in the near future;
everything else will take longer.
Full Story (comments: 75)
Kernel development news
As of this writing, kernel.org 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 kernel.org, that will not run anywhere
near as smoothly as the community might like. Still, some things cannot be
rushed, and it is important that kernel.org come back in a solid and secure
Quite a few trees have found new homes in the mean time. Here is an
updated version of the list of relocated trees:
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
kernel.org. Those trees will not have seen any updates since kernel.org
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
kernel.org does not come back soon, they will need to find a different
One significant tree that has not moved is the stable release tree; the
last stable updates came out on August 29.
With luck, kernel.org will come back soon and the above list will become
moot. But kernel.org, 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)
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 kernel.org. 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|
|Mauro Carvalho Chehab||127||1.5%|
|Arend van Spriel||105||1.2%|
|David S. Miller||63||0.7%|
|By changed lines|
|Arend van Spriel||15659||1.9%|
|Mauro Carvalho Chehab||12974||1.6%|
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
|Most active 3.0 employers|
|By lines changed|
|Metzler Brothers Systementwicklung GbR||23681||2.9%|
|Rising Tide Systems||23090||2.8%|
|South Pole AB||12087||1.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
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 kernel.org 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)
"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
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
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, ¶m);
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
Comments (21 posted)
Patches and updates
Core kernel code
Filesystems and block I/O
Page editor: Jonathan Corbet
Next page: Distributions>>