Kernel Traffic #326 by Zack Brown
[email protected] Mon, 05 Sep 2005 11:00:12 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #326 For 5 Sep
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Introduction
* Mailing List Stats For This Week
* Threads Covered
1. 23 Aug - 29 Aug (34 Linux 2.6.13-rc7 Released
posts)
2. 25 Aug - 29 Aug (5 New Test Release Of SPUFS; Some Discussion Of
posts) Source Tree Location
3. 26 Aug - 30 Aug (36 HDAPS Accelerometer Driver; Hardware Detection
posts) Problems
4. 29 Aug (2 Linux 2.6.12.6 Released
posts)
5. 29 Aug - 1 Sep (10 MPC8xx PCMCIA Driver Wends Its Way Into 2.6
posts)
6. 29 Aug - 1 Sep (33 Monitoring Kernel Use Among Consenting Users
posts)
Introduction
*whew*! OK, once again I'm all caught up with Kernel Traffic. Now I'm going to
really try to keep future issues to a weekly schedule. If you see me slacking
off, feel free to give me a nudge.
Also, I'd like to thank the folks who catch spelling errors (my own, not the
folks I quote), factual inaccuracies, partially completed summaries, bad dates,
and so on, and report them to me. This is extremely useful, and I appreciate it
very much.
For the lawyers who occassionally threaten me with litigation because I've
quoted something that sounds unfavorable to their client, I don't thank them,
and I'd like them to please leave me alone. But I suppose that is too much to
hope for... If any KT-friendly lawers out there would like to do some pro bono
work when one of that bunch tries to lean on me, I'd appreciate it. The most
recent time was just a couple months ago, but I think they've gone away.
Mailing List Stats For This Week
We looked at 1796 posts in 12MB.
There were 647 different contributors. 256 posted more than once. The average
length of each message was 140 lines.
+-----------------------------------------------------------------------------+
| The top posters of the | The top subjects of the week were: |
| week were: | |
|------------------------+----------------------------------------------------|
|53 posts in 327KB by | |
|steven rostedt |42 posts in 192KB for "2.6.12 performance problems" |
|45 posts in 175KB by |36 posts in 141KB for "[patch] ibm hdaps |
|ingo molnar |accelerometer driver." |
|44 posts in 228KB by |34 posts in 146KB for "process creation time |
|jesper juhl |increases linearly with shmem" |
|35 posts in 701KB by tom|33 posts in 163KB for "linux-2.6.13-rc7" |
|rini |33 posts in 123KB for "klive: linux kernel live |
|35 posts in 116KB by |usage monitor" |
|alan cox | |
+-----------------------------------------------------------------------------+
Full Statistics generated by mboxstats version 2.8
1. Linux 2.6.13-rc7 Released
23 Aug - 29 Aug (34 posts) Archive Link: "Linux-2.6.13-rc7"
Topics: Kernel Release Announcement
People: Linus Torvalds
Linus Torvalds announced Linux 2.6.13-rc7, saying:
I really wanted to release a 2.6.13, but there's been enough changes while
we've been waiting for other issues to resolve that I think it's best to do
a -rc7 first.
Most of the -rc7 changes are pretty trivial, either one-liners or affecting
some particular specific driver or unusual configuration. The shortlog
(appended) should give a pretty good idea of what's up.
2. New Test Release Of SPUFS; Some Discussion Of Source Tree Location
25 Aug - 29 Aug (5 posts) Archive Link: "[PATCH 1/7] spufs: The SPU file
system"
People: Arnd Bergmann, Pekka Enberg, Geoff Levand
Arnd Bergmann said:
This is a work-in-progress version of the SPU file system.
Since the previous version, a lot of features have been added and a number
of bugs has been fixed. We now support doing read() on the /run file to
start executing code on an SPU. Some files have been added to give access
to more hardware features, especially the signal notification channels.
Most importantly, we now have a working context save and restore
functionality for SPEs, which is written by Mark Nutter and will eventually
lead to having a scheduler for SPUs in the kernel. Since this has grown the
file system a lot, I now split it up into a few smaller patches.
Within the next weeks, we will do some larger reworks on the code base, so
this version is probably the last one that is binary compatible to the
earlier releases.
If you have specific requirements that are not met by spufs in its present
incarnation, now would be a good time to tell us.
Pekka Enberg replied, "I am confused. The code is architecture specific and
does device I/O. Why do you want to put this in fs/ and not drivers/?" Arnd
replied:
I never really thought of it as a device driver but rather an architecture
extension, so it started out in arch/ppc64/kernel. Since most of the code
is interacting with VFS, it is now in fs/spufs. I don't really care about
the location, but I among the possible places to put the code (with the
unified arch/powerpc tree), I'd suggest (best first)
1. arch/powerpc/platforms/cell
2. arch/powerpc/spe
3. fs/spufs
4. drivers/spe
1) would be the place where I want to have the low-level code (currently
arch/ppc64/kernel/spu_base.c) anyway, so it makes sense to have everything
in there that I maintain.
2) might work better if we at a later point have multiple platform types in
arch/powerpc that use SPEs, e.g if we want to keep Playstation code
separate from generic Cell.
Pekka replied, "I am happy with 1, 2, and 4. You could, of course, abstract
away the general purpose parts of spufs (for example, if we had other similar
architecture extensions that could share the code) and put them in 3 but that
would probably just introduce unnecessary complexity." And Geoff Levand
offered, "I think putting it in 'arch/powerpc/platforms/cell' is fine for now.
We'll be better able to judge if we need to and how to split off platform
specifics when we have code for more cell platforms."
3. HDAPS Accelerometer Driver; Hardware Detection Problems
26 Aug - 30 Aug (36 posts) Archive Link: "[patch] IBM HDAPS accelerometer
driver."
Topics: PCI, Power Management: ACPI
People: Robert Love, Brian Gerst, Arjan van de Ven, Alan Cox, Dave Jones, Jeff
Garzik
Robert Love said:
I have been working on a driver for the IBM Hard Drive Active Protection
System (HDAPS), which provides a two-axis accelerometer and some other
misc. data. The hardware is found on recent IBM ThinkPad laptops.
The following patch adds the driver to 2.6.13-rc6-mm2. It is self-contained
and fairly simple.
Brian Gerst asked, "Is there any way to detect that this device is present
(PCI, ACPI, etc.) without poking at ports?" Robert replied, "Not that we've
been able to tell. It is a legacy platform device. So, unfortunately, no probe
() routine." Arjan van de Ven suggested, "dmi surely...." Robert said he's
welcome any patches for this, and Alan Cox said, "I think that should be fixed
before its merged." Robert replied:
Let me be clear, it has an init routine that effectively probes for the
device.
It just lacks a simple quick non-invasive check.
The driver will definitely fail to load on a laptop without the requisite
hardware.
Dave Jones remarked, "Poking IO ports on hardware where you don't have the
device can be fatal. What happens if I have something completely different at
io port 0x1600 ? (Thus satisfying your request_region() check).
accelerometer_init() then happily starts poking ports, and performing all kinds
of voodoo."
And close by, Jeff Garzik said of the DMI solution, "Since such a check is
possible, that's definitely a merge-stopper IMO" . Robert replied:
First, I am not asking that Linus merge this. Everyone needs to relax.
Second, we don't know a DMI-based solution will work. I'll check it out.
4. Linux 2.6.12.6 Released
29 Aug (2 posts) Archive Link: "Linux 2.6.12.6"
Topics: Capabilities, Compression
People: Chris Wright, Patrick McHardy, Chris Wright:, Bhavesh P. Davda, Linus
Torvalds
Chris Wright announced Linux 2.6.12.6, saying:
We (the -stable team) are announcing the release of the 2.6.12.6 kernel.
This is final one for 2.6.12 now that 2.6.13 has been released.
The diffstat and short summary of the fixes are below.
I'll also be replying to this message with a copy of the patch between
2.6.12.5 and 2.6.12.6, as it is small enough to do so.
The updated 2.6.12.y git tree can be found at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/ (http://www.kernel.org/git/)
Summary of changes from v2.6.12.5 to v2.6.12.6
==============================================
Bhavesh P. Davda: NPTL signal delivery deadlock fix
Chris Wright:
Linux 2.6.12.6
Herbert Xu:
Restrict socket policy loading to CAP_NET_ADMIN - CAN-2005-2555
Jan Blunck:
sg.c: fix a memory leak in devices seq_file implementation (2nd)
lepton:
fix gl_skb/skb type error in genelink driver in usbnet
Linus Torvalds:
Revert unnecessary zlib_inflate/inftrees.c fix
Patrick McHardy:
Fix DST leak in icmp_push_reply()
Fix SKB leak in ip6_input_finish()
5. MPC8xx PCMCIA Driver Wends Its Way Into 2.6
29 Aug - 1 Sep (10 posts) Archive Link: "[PATCH] MPC8xx PCMCIA driver"
Topics: Forward Port
People: Marcelo Tosatti, Magnus Damm
Marcelo Tosatti said:
Here goes the 8xx PCMCIA driver, originally written by Magnus Damm, with
several improvements and fixes.
The driver was merged in v2.4 but never forward ported to v2.6.
Please review, comments are welcome (including aesthetic enhancements).
Magnus Damm replied at one point:
Nice to see that this driver gets forward ported to 2.6. I originally wrote
it for pcmcia-cs, but it made its way into 2.4 after a while. Thanks to all
the people who added code and fixes.
I'm not sure how the current Linux pcmcia layer works, and I am not
involved in powerpc land anymore so I have no comments on the porting work
or the driver itself.
6. Monitoring Kernel Use Among Consenting Users
29 Aug - 1 Sep (33 posts) Archive Link: "KLive: Linux Kernel Live Usage
Monitor"
Topics: Bug Tracking, Disks: IDE
People: Andrea Arcangeli, Alan Cox, Sven Ladegast
Andrea Arcangeli said:
During the Kernel Summit somebody raised the point that it's not clear how
much testing each rc/pre/git kernel gets before the final release.
So I setup a server to track automatically the amount of testing that each
kernel gets. Clearly this will be a very rough approximation and it can't
be reliable, but perhaps it'll be useful. If this won't be useful, the time
I spent on it is very minor so no problem ;).
All the details can be found in the project website:
http://klive.cpushare.com/
Full source (server included) is here:
http://klive.cpushare.com/downloads/klive-0.0.tar.bz2
To run the client:
wget http://klive.cpushare.com/klive.tac
Then at every boot (like in /etc/init.d/boot.local):
twistd -oy klive.tac
In theory we could get rid of the client entirely and make it a kernel
config option, but I've no idea if this project is useful, so I don't want
to spend too much time on it at this point.
There was some discussion that public perception might put this in the
"spyware" category. At one point Alan Cox said the an "opt in" requirement
would be essential. He said, "That might lower coverage but should increase
quality, especially id the id in the cookie can be put into bugzilla reports,
and the hardware reporting is done so it can be machine processed (ie so you
can ask stuff like 'reliability with Nvidia IDE')" . And Sven Ladegast agreed,
"A change in the kernel sources which automagically sends data, regardless what
kind of data, to somewhere in the net must not be enabled by default." And Alan
added, "We don't need personally identifiable data (email, name, ip address
etc.) What to do with it will be most interesting indeed."
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor
Greg Benson and Professor Allan Cruse in the Department of Computer Science at
the University of San Francisco. This is the same department that invented
FlashMob Computing. Kernel Traffic is hosted by the generous folks at
kernel.org. All pages on this site are copyright their original authors, and
distributed under the terms of the GNU General Public License, version 2.0.