Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic|
Table Of Contents
|1.||23 Aug 2005 - 29 Aug 2005||(34 posts)||Linux 2.6.13-rc7 Released|
|2.||25 Aug 2005 - 29 Aug 2005||(5 posts)||New Test Release Of SPUFS; Some Discussion Of Source Tree Location|
|3.||26 Aug 2005 - 30 Aug 2005||(36 posts)||HDAPS Accelerometer Driver; Hardware Detection Problems|
|4.||29 Aug 2005||(2 posts)||Linux 18.104.22.168 Released|
|5.||29 Aug 2005 - 1 Sep 2005||(10 posts)||MPC8xx PCMCIA Driver Wends Its Way Into 2.6|
|6.||29 Aug 2005 - 1 Sep 2005||(33 posts)||Monitoring Kernel Use Among Consenting Users|
*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 lawyers 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. See the Full Statistics.
There were 647 different contributors. 256 posted more than once. The average length of each message was 140 lines.
|The top posters of the week were:||The top subjects of the week were:|
|53 posts in 327KB by steven rostedt
45 posts in 175KB by ingo molnar
44 posts in 228KB by jesper juhl
35 posts in 701KB by tom rini
35 posts in 116KB by alan cox
|42 posts in 192KB for "2.6.12 performance problems"
36 posts in 141KB for "[patch] ibm hdaps accelerometer driver."
34 posts in 146KB for "process creation time increases linearly with shmem"
33 posts in 163KB for "linux-2.6.13-rc7"
33 posts in 123KB for "klive: linux kernel live usage monitor"
These stats generated by mboxstats version 2.8
1. Linux 2.6.13-rc7 Released
23 Aug 2005 - 29 Aug 2005 (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 2005 - 29 Aug 2005 (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) 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 2005 - 30 Aug 2005 (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'd 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 22.214.171.124 Released
29 Aug 2005 (2 posts) Archive Link: "Linux 126.96.36.199"
Topics: Capabilities, Compression
People: Chris Wright, Patrick McHardy, Chris Wright:, Bhavesh P. Davda, Linus Torvalds
Chris Wright announced Linux 188.8.131.52, saying:
We (the -stable team) are announcing the release of the 184.108.40.206 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 220.127.116.11 and 18.104.22.168, as it is small enough to do so.
The updated 2.6.12.y git tree can be found at:
and can be browsed at the normal kernel.org git web browser:
Summary of changes from v22.214.171.124 to v126.96.36.199
Bhavesh P. Davda: NPTL signal delivery deadlock fix
Restrict socket policy loading to CAP_NET_ADMIN - CAN-2005-2555
sg.c: fix a memory leak in devices seq_file implementation (2nd)
fix gl_skb/skb type error in genelink driver in usbnet
Revert unnecessary zlib_inflate/inftrees.c fix
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 2005 - 1 Sep 2005 (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 2005 - 1 Sep 2005 (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:
Full source (server included) is here:
To run the client:
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 that 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