LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Kernel developmentBrief items Kernel release statusThe 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 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 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 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 week.
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.
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
A kernel.org status updateThe 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 before." Git trees should go back online in the near future; everything else will take longer.
Kernel development news The forest on the moveAs 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 mode.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 home. 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.
A look at the 3.1 development cycleAs 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:
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:
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 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.
A new approach to opportunistic suspend"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, ¶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:
sched_deboost_task_active_count(current);
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.
Patches and updates Kernel trees
Core kernel code
Development tools
Device drivers
Documentation
Filesystems and block I/O
Memory management
Architecture-specific
Miscellaneous
Page editor: Jonathan Corbet |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![[chart]](/images/2011/rc-csets.png)