<?xml version="1.0" ?>

<kc>

<title>Kernel Traffic</title>

<author contact="mailto:zbrown@tumblerings.org">Zack Brown</author>

<issue num="326" date="05 Sep 2005 00:00:00 -0800" />

<intro>

<p>*whew*! OK, once again I'm all caught up with Kernel Traffic. Now I'm
going to <i>really try</i> to keep future issues to a weekly schedule. If
you see me slacking off, feel free to give me a nudge.</p>

<p>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.</p>

<p>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.</p>

</intro>

<mailbox-stats>
	<global-stats>
		<generated-at>Mon Sep  5 00:25:28 2005</generated-at>
		<first-message>Tue Aug 16 12:31:56 2005</first-message>
		<last-message>Fri Sep  2 16:13:31 2005</last-message>
		<totals>
			<n-messages>1796</n-messages>
			<n-is-reply>1299</n-is-reply>
			<avg-resp-time>539:23:34</avg-resp-time>
			<n-pgp-signed>46</n-pgp-signed>
			<total-size>12MB</total-size>
			<avg-size>7KB</avg-size>
			<n-attachments>57</n-attachments>
			<att-size>343KB</att-size>
			<bussiest-day-in-n day="2005-08-30"><n-msgs>294</n-msgs><n-bytes>2MB</n-bytes></bussiest-day-in-n>
			<bussiest-day-in-bytes day="2005-09-01"><n-msgs>282</n-msgs><n-bytes>3MB</n-bytes></bussiest-day-in-bytes>
			<n-writers>647</n-writers>
			<wrote-more-then-1-message>256</wrote-more-then-1-message>
			<n-lines>251522</n-lines>
			<header-size>96869</header-size>
			<n-user-agents>65</n-user-agents>
			<n-organisations>51</n-organisations>
			<n-toplevel-domains>39</n-toplevel-domains>
			<avg-spam-score>-13.927394</avg-spam-score>
				<spammiest-writer><score>4.099000</score><name>"</name></spammiest-writer>
		</totals>
		<averages>
			<lines-per-message>140</lines-per-message>
			<lines-per-header>53</lines-per-header>
			<header-percent-of-message>38.51%</header-percent-of-message>
			<header-percent-of-total>37.63%</header-percent-of-total>
			<line-length>27</line-length>
		</averages>
		<importance>
			<low>0.00%</low>
			<normal>0.28%</normal>
			<high>0.00%</high>
		</importance>

	</global-stats>
	<top-writers>
		<top-writer rank="1">
			<e-mail-addr>steven&#32;rostedt</e-mail-addr>
			<n-messages>53</n-messages>
			<avg-size>7KB</avg-size>
			<total-size>327KB</total-size>
			<mostly-written-at>14:30</mostly-written-at>
		</top-writer>
		<top-writer rank="2">
			<e-mail-addr>ingo&#32;molnar</e-mail-addr>
			<n-messages>45</n-messages>
			<avg-size>4KB</avg-size>
			<total-size>175KB</total-size>
			<mostly-written-at>12:42</mostly-written-at>
		</top-writer>
		<top-writer rank="3">
			<e-mail-addr>jesper&#32;juhl</e-mail-addr>
			<n-messages>44</n-messages>
			<avg-size>6KB</avg-size>
			<total-size>228KB</total-size>
			<mostly-written-at>15:39</mostly-written-at>
		</top-writer>
		<top-writer rank="4">
			<e-mail-addr>tom&#32;rini</e-mail-addr>
			<n-messages>35</n-messages>
			<avg-size>21KB</avg-size>
			<total-size>701KB</total-size>
			<mostly-written-at>10:43</mostly-written-at>
		</top-writer>
		<top-writer rank="5">
			<e-mail-addr>alan&#32;cox</e-mail-addr>
			<n-messages>35</n-messages>
			<avg-size>4KB</avg-size>
			<total-size>116KB</total-size>
			<mostly-written-at>16:22</mostly-written-at>
		</top-writer>
	</top-writers>
	<top-subjects>
		<top-subject rank="1">
			<subject>2.6.12&#32;performance&#32;problems</subject>
			<n-messages>42</n-messages>
			<avg-size>5KB</avg-size>
			<total-size>192KB</total-size>
			<mostly-written-at>14:42</mostly-written-at>
			<first-msg>1124642814</first-msg>
			<last-msg>1125184745</last-msg>
		</top-subject>
		<top-subject rank="2">
			<subject>[patch]&#32;ibm&#32;hdaps&#32;accelerometer&#32;driver.</subject>
			<n-messages>36</n-messages>
			<avg-size>4KB</avg-size>
			<total-size>141KB</total-size>
			<mostly-written-at>14:09</mostly-written-at>
			<first-msg>1125083894</first-msg>
			<last-msg>1125461539</last-msg>
		</top-subject>
		<top-subject rank="3">
			<subject>process&#32;creation&#32;time&#32;increases&#32;linearly&#32;with&#32;shmem</subject>
			<n-messages>34</n-messages>
			<avg-size>5KB</avg-size>
			<total-size>146KB</total-size>
			<mostly-written-at>12:42</mostly-written-at>
			<first-msg>1124923409</first-msg>
			<last-msg>1125426558</last-msg>
		</top-subject>
		<top-subject rank="4">
			<subject>linux-2.6.13-rc7</subject>
			<n-messages>33</n-messages>
			<avg-size>5KB</avg-size>
			<total-size>163KB</total-size>
			<mostly-written-at>13:48</mostly-written-at>
			<first-msg>1124863693</first-msg>
			<last-msg>1125358424</last-msg>
		</top-subject>
		<top-subject rank="5">
			<subject>klive:&#32;linux&#32;kernel&#32;live&#32;usage&#32;monitor</subject>
			<n-messages>33</n-messages>
			<avg-size>4KB</avg-size>
			<total-size>123KB</total-size>
			<mostly-written-at>14:08</mostly-written-at>
			<first-msg>1125407399</first-msg>
			<last-msg>1125624224</last-msg>
		</top-subject>
	</top-subjects>
	<top-receivers>
		<top-receiver rank="1">
			<e-mail-addr>linux-kernel@vger.kernel.org</e-mail-addr>
			<n-messages>301</n-messages>
			<avg-size>11KB</avg-size>
			<total-size>4MB</total-size>
			<mostly-written-at>14:19</mostly-written-at>
		</top-receiver>
		<top-receiver rank="2">
			<e-mail-addr>akpm@osdl.org</e-mail-addr>
			<n-messages>194</n-messages>
			<avg-size>12KB</avg-size>
			<total-size>3MB</total-size>
			<mostly-written-at>14:10</mostly-written-at>
		</top-receiver>
		<top-receiver rank="3">
			<e-mail-addr>ingo&#32;molnar</e-mail-addr>
			<n-messages>75</n-messages>
			<avg-size>8KB</avg-size>
			<total-size>551KB</total-size>
			<mostly-written-at>11:30</mostly-written-at>
		</top-receiver>
		<top-receiver rank="4">
			<e-mail-addr>linus&#32;torvalds</e-mail-addr>
			<n-messages>53</n-messages>
			<avg-size>8KB</avg-size>
			<total-size>390KB</total-size>
			<mostly-written-at>13:13</mostly-written-at>
		</top-receiver>
		<top-receiver rank="5">
			<e-mail-addr>steven&#32;rostedt</e-mail-addr>
			<n-messages>36</n-messages>
			<avg-size>5KB</avg-size>
			<total-size>160KB</total-size>
			<mostly-written-at>14:31</mostly-written-at>
		</top-receiver>
	</top-receivers>
	<top-ccers>
		<top-ccers rank="1">
			<e-mail-addr>linux-kernel@vger.kernel.org</e-mail-addr>
			<n-messages>860</n-messages>
			<avg-size>7KB</avg-size>
			<total-size>6MB</total-size>
			<mostly-written-at>13:54</mostly-written-at>
		</top-ccers>
		<top-ccers rank="2">
			<e-mail-addr>andrew&#32;morton</e-mail-addr>
			<n-messages>188</n-messages>
			<avg-size>6KB</avg-size>
			<total-size>2MB</total-size>
			<mostly-written-at>14:09</mostly-written-at>
		</top-ccers>
		<top-ccers rank="3">
			<e-mail-addr>linus&#32;torvalds</e-mail-addr>
			<n-messages>53</n-messages>
			<avg-size>7KB</avg-size>
			<total-size>350KB</total-size>
			<mostly-written-at>12:53</mostly-written-at>
		</top-ccers>
		<top-ccers rank="4">
			<e-mail-addr>ingo&#32;molnar</e-mail-addr>
			<n-messages>53</n-messages>
			<avg-size>6KB</avg-size>
			<total-size>299KB</total-size>
			<mostly-written-at>16:26</mostly-written-at>
		</top-ccers>
		<top-ccers rank="5">
			<e-mail-addr>thomas&#32;gleixner</e-mail-addr>
			<n-messages>43</n-messages>
			<avg-size>6KB</avg-size>
			<total-size>235KB</total-size>
			<mostly-written-at>13:49</mostly-written-at>
		</top-ccers>
	</top-ccers>
	<top-level-domains>
		<tld rank="1">
			<name>com</name>
			<freq>798</freq>
			<avg-size>8KB</avg-size>
			<total-size>6MB</total-size>
		</tld>
		<tld rank="2">
			<name>org</name>
			<freq>333</freq>
			<avg-size>8KB</avg-size>
			<total-size>3MB</total-size>
		</tld>
		<tld rank="3">
			<name>de</name>
			<freq>141</freq>
			<avg-size>7KB</avg-size>
			<total-size>890KB</total-size>
		</tld>
		<tld rank="4">
			<name>net</name>
			<freq>101</freq>
			<avg-size>4KB</avg-size>
			<total-size>366KB</total-size>
		</tld>
		<tld rank="5">
			<name>uk</name>
			<freq>75</freq>
			<avg-size>4KB</avg-size>
			<total-size>257KB</total-size>
		</tld>
	</top-level-domains>
	<top-timezones>
		<tz rank="1">
			<name>+0200</name>
			<freq>535</freq>
			<avg-size>6KB</avg-size>
			<total-size>4MB</total-size>
		</tz>
		<tz rank="2">
			<name>-0700</name>
			<freq>364</freq>
			<avg-size>7KB</avg-size>
			<total-size>3MB</total-size>
		</tz>
		<tz rank="3">
			<name>-0400</name>
			<freq>281</freq>
			<avg-size>7KB</avg-size>
			<total-size>2MB</total-size>
		</tz>
		<tz rank="4">
			<name>+0100</name>
			<freq>125</freq>
			<avg-size>6KB</avg-size>
			<total-size>631KB</total-size>
		</tz>
		<tz rank="5">
			<name>-0500</name>
			<freq>113</freq>
			<avg-size>7KB</avg-size>
			<total-size>709KB</total-size>
		</tz>
	</top-timezones>
	<top-organisations>
		<org rank="1">
			<name>kihon&#32;technologies</name>
			<freq>52</freq>
			<bytes>323KB</bytes>
		</org>
		<org rank="2">
			<name>montavista</name>
			<freq>21</freq>
			<bytes>74KB</bytes>
		</org>
		<org rank="3">
			<name>montavista&#32;software</name>
			<freq>11</freq>
			<bytes>51KB</bytes>
		</org>
		<org rank="5">
			<name>harddisk-recovery.com</name>
			<freq>9</freq>
			<bytes>35KB</bytes>
		</org>
	</top-organisations>
	<top-user-agents>
		<useragent rank="1">
			<name>mozilla</name>
			<freq>52</freq>
			<bytes>760KB</bytes>
		</useragent>
		<useragent rank="2">
			<name>evolution</name>
			<freq>46</freq>
			<bytes>2MB</bytes>
		</useragent>
		<useragent rank="3">
			<name>mutt/1.5.9i</name>
			<freq>34</freq>
			<bytes>2MB</bytes>
		</useragent>
		<useragent rank="4">
			<name>mozilla/5.0</name>
			<freq>25</freq>
			<bytes>407KB</bytes>
		</useragent>
		<useragent rank="5">
			<name>mutt/1.4.1i</name>
			<freq>17</freq>
			<bytes>2MB</bytes>
		</useragent>
	</top-user-agents>
	<messages-per-day>
		<Sunday><msgs>96</msgs><bytes>485KB</bytes></Sunday>
		<Monday><msgs>233</msgs><bytes>2MB</bytes></Monday>
		<Tuesday><msgs>326</msgs><bytes>2MB</bytes></Tuesday>
		<Wednesday><msgs>319</msgs><bytes>3MB</bytes></Wednesday>
		<Thursday><msgs>435</msgs><bytes>4MB</bytes></Thursday>
		<Friday><msgs>277</msgs><bytes>2MB</bytes></Friday>
		<Saturday><msgs>91</msgs><bytes>492KB</bytes></Saturday>
	</messages-per-day>
	<messages-per-month>
		<Jan><msgs>0</msgs><bytes>0</bytes></Jan>
		<Feb><msgs>0</msgs><bytes>0</bytes></Feb>
		<Mar><msgs>0</msgs><bytes>0</bytes></Mar>
		<Apr><msgs>0</msgs><bytes>0</bytes></Apr>
		<May><msgs>0</msgs><bytes>0</bytes></May>
		<Jun><msgs>0</msgs><bytes>0</bytes></Jun>
		<Jul><msgs>0</msgs><bytes>0</bytes></Jul>
		<Aug><msgs>1466</msgs><bytes>9MB</bytes></Aug>
		<Sep><msgs>311</msgs><bytes>3MB</bytes></Sep>
		<Oct><msgs>0</msgs><bytes>0</bytes></Oct>
		<Nov><msgs>0</msgs><bytes>0</bytes></Nov>
		<Dec><msgs>0</msgs><bytes>0</bytes></Dec>
	</messages-per-month>
	<messages-per-day-of-month>
		<day-1><msgs>282</msgs><bytes>3MB</bytes></day-1>
		<day-2><msgs>29</msgs><bytes>317KB</bytes></day-2>
		<day-3><msgs>0</msgs><bytes>0</bytes></day-3>
		<day-4><msgs>0</msgs><bytes>0</bytes></day-4>
		<day-5><msgs>0</msgs><bytes>0</bytes></day-5>
		<day-6><msgs>0</msgs><bytes>0</bytes></day-6>
		<day-7><msgs>0</msgs><bytes>0</bytes></day-7>
		<day-8><msgs>0</msgs><bytes>0</bytes></day-8>
		<day-9><msgs>0</msgs><bytes>0</bytes></day-9>
		<day-10><msgs>0</msgs><bytes>0</bytes></day-10>
		<day-11><msgs>0</msgs><bytes>0</bytes></day-11>
		<day-12><msgs>0</msgs><bytes>0</bytes></day-12>
		<day-13><msgs>0</msgs><bytes>0</bytes></day-13>
		<day-14><msgs>0</msgs><bytes>0</bytes></day-14>
		<day-15><msgs>0</msgs><bytes>0</bytes></day-15>
		<day-16><msgs>13</msgs><bytes>56KB</bytes></day-16>
		<day-17><msgs>18</msgs><bytes>159KB</bytes></day-17>
		<day-18><msgs>4</msgs><bytes>13KB</bytes></day-18>
		<day-19><msgs>6</msgs><bytes>35KB</bytes></day-19>
		<day-20><msgs>1</msgs><bytes>21KB</bytes></day-20>
		<day-21><msgs>9</msgs><bytes>43KB</bytes></day-21>
		<day-22><msgs>16</msgs><bytes>93KB</bytes></day-22>
		<day-23><msgs>19</msgs><bytes>108KB</bytes></day-23>
		<day-24><msgs>57</msgs><bytes>424KB</bytes></day-24>
		<day-25><msgs>149</msgs><bytes>747KB</bytes></day-25>
		<day-26><msgs>242</msgs><bytes>2MB</bytes></day-26>
		<day-27><msgs>90</msgs><bytes>472KB</bytes></day-27>
		<day-28><msgs>87</msgs><bytes>443KB</bytes></day-28>
		<day-29><msgs>217</msgs><bytes>2MB</bytes></day-29>
		<day-30><msgs>294</msgs><bytes>2MB</bytes></day-30>
		<day-31><msgs>244</msgs><bytes>2MB</bytes></day-31>
	</messages-per-day-of-month>
	<messages-per-hour>
		<hour-1><msgs>33</msgs><bytes>187KB</bytes></hour-1>
		<hour-2><msgs>24</msgs><bytes>206KB</bytes></hour-2>
		<hour-3><msgs>18</msgs><bytes>96KB</bytes></hour-3>
		<hour-4><msgs>5</msgs><bytes>26KB</bytes></hour-4>
		<hour-5><msgs>8</msgs><bytes>54KB</bytes></hour-5>
		<hour-6><msgs>6</msgs><bytes>82KB</bytes></hour-6>
		<hour-7><msgs>41</msgs><bytes>173KB</bytes></hour-7>
		<hour-8><msgs>53</msgs><bytes>316KB</bytes></hour-8>
		<hour-9><msgs>106</msgs><bytes>2MB</bytes></hour-9>
		<hour-10><msgs>107</msgs><bytes>592KB</bytes></hour-10>
		<hour-11><msgs>136</msgs><bytes>847KB</bytes></hour-11>
		<hour-12><msgs>111</msgs><bytes>524KB</bytes></hour-12>
		<hour-13><msgs>105</msgs><bytes>526KB</bytes></hour-13>
		<hour-14><msgs>139</msgs><bytes>724KB</bytes></hour-14>
		<hour-15><msgs>119</msgs><bytes>523KB</bytes></hour-15>
		<hour-16><msgs>129</msgs><bytes>720KB</bytes></hour-16>
		<hour-17><msgs>94</msgs><bytes>536KB</bytes></hour-17>
		<hour-18><msgs>103</msgs><bytes>805KB</bytes></hour-18>
		<hour-19><msgs>84</msgs><bytes>420KB</bytes></hour-19>
		<hour-20><msgs>75</msgs><bytes>607KB</bytes></hour-20>
		<hour-21><msgs>85</msgs><bytes>2MB</bytes></hour-21>
		<hour-22><msgs>62</msgs><bytes>433KB</bytes></hour-22>
		<hour-23><msgs>63</msgs><bytes>380KB</bytes></hour-23>
	</messages-per-hour>
	<urls>
		<url-1><freq>1387</freq><url>http://vger.kernel.org/majordomo-info.html</url></url-1>
		<url-2><freq>1387</freq><url>http://www.tux.org/lkml/</url></url-2>
		<url-3><freq>17</freq><url>http://www.yahoo.com/r/hs</url></url-3>
		<url-4><freq>15</freq><url>http://www.opensource.org/licenses/osl-1.1.txt</url></url-4>
		<url-5><freq>8</freq><url>http://redhat.com/~mingo/realtime-preempt/</url></url-5>
	</urls>
	<top-avg-resp>
		<resp-pers rank="1">
			<name>prasanna&#32;s&#32;panchamukhi</name>
			<avg-resp-time>00:01:22</avg-resp-time>
			<n-replies>1</n-replies>
		</resp-pers>
		<resp-pers rank="2">
			<name>tony&#32;jones</name>
			<avg-resp-time>00:03:47</avg-resp-time>
			<n-replies>1</n-replies>
		</resp-pers>
		<resp-pers rank="3">
			<name>jesse&#32;barnes</name>
			<avg-resp-time>00:05:17</avg-resp-time>
			<n-replies>1</n-replies>
		</resp-pers>
		<resp-pers rank="4">
			<name>nathan&#32;lynch</name>
			<avg-resp-time>00:07:55</avg-resp-time>
			<n-replies>1</n-replies>
		</resp-pers>
		<resp-pers rank="5">
			<name>florian&#32;weimer</name>
			<avg-resp-time>00:11:26</avg-resp-time>
			<n-replies>1</n-replies>
		</resp-pers>
		<resp-pers rank="6">
			<name>brice&#32;goglin</name>
			<avg-resp-time>00:13:23</avg-resp-time>
			<n-replies>1</n-replies>
		</resp-pers>
	</top-avg-resp>
	<created-with><name>mboxstats</name><version>2.8</version><developer>folkert@vanheusden.com</developer><url>http://www.vanheusden.com/mboxstats/</url></created-with>
</mailbox-stats>

<section
  title="Linux 2.6.13-rc7 Released"
  subject="Linux-2.6.13-rc7"
  archive="http://groups.google.com/group/fa.linux.kernel/msg/6b5c661bfaca1ef8?hl=en"
  posts="34"
  startdate="23 Aug 2005 21:08:13 -0800"
  enddate="29 Aug 2005 05:33:44 -0800"
>
<topic>Kernel Release Announcement</topic>

<p>Linus Torvalds announced Linux 2.6.13-rc7, saying:</p>

<quote who="Linus Torvalds">

<p>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.</p>

<p>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.</p>

</quote>

</section>

<section
  title="New Test Release Of SPUFS; Some Discussion Of Source Tree Location"
  subject="[PATCH 1/7] spufs: The SPU file system"
  archive="http://groups.google.com/group/fa.linux.kernel/msg/286a464ed1838c20?hl=en"
  posts="5"
  startdate="25 Aug 2005 14:03:39 -0800"
  enddate="29 Aug 2005 10:09:49 -0800"
>

<p>Arnd Bergmann said:</p>

<quote who="Arnd Bergmann">

<p>This is a work-in-progress version of the SPU file system.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>If you have specific requirements that are not met by spufs in its present
incarnation, now would be a good time to tell us.</p>

</quote>

<p>Pekka Enberg replied, <quote who="Pekka Enberg">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/?</quote> Arnd replied:</p>

<quote who="Arnd Bergmann">

<p>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)</p>

<ol>

<li>arch/powerpc/platforms/cell</li>
<li>arch/powerpc/spe</li>
<li>fs/spufs</li>
<li>drivers/spe</li>

</ol>

<p>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.</p>

<p>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.</p>

</quote>

<p>Pekka replied, <quote who="Pekka Enberg">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.</quote> And Geoff Levand offered, <quote who="Geoff
Levand">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.</quote></p>

</section>

<section
  title="HDAPS Accelerometer Driver; Hardware Detection Problems"
  subject="[patch] IBM HDAPS accelerometer driver."
  archive="http://groups.google.com/group/linux.kernel/msg/47e6bd8606011449?hl=en"
  posts="36"
  startdate="26 Aug 2005 07:18:14 -0800"
  enddate="30 Aug 2005 16:12:19 -0800"
>
<topic>PCI</topic>
<topic>Power Management: ACPI</topic>

<p>Robert Love said:</p>

<quote who="Robert Love">

<p>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.</p>

<p>The following patch adds the driver to 2.6.13-rc6-mm2.  It is
self-contained and fairly simple.</p>

</quote>

<p>Brian Gerst asked, <quote who="Brian Gerst">Is there any way to
detect that this device is present (PCI, ACPI, etc.) without poking at
ports?</quote> Robert replied, <quote who="Robert Love">Not that we've
been able to tell. It is a legacy platform device. So, unfortunately, no
probe() routine.</quote> Arjan van de Ven suggested, <quote who="Arjan van
de Ven">dmi surely....</quote> Robert said he'd welcome any patches for this,
and Alan Cox said, <quote who="Alan Cox">I think that should be fixed before
its merged.</quote> Robert replied:</p>

<quote who="Robert Love">

<p>Let me be clear, it has an init routine that effectively probes for the
device.</p>

<p>It just lacks a simple quick non-invasive check.</p>

<p>The driver will definitely fail to load on a laptop without the
requisite hardware.</p>

</quote>

<p>Dave Jones remarked, <quote who="Dave Jones">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.</quote></p>

<p>And close by, Jeff Garzik said of the DMI solution, <quote who="Jeff
Garzik">Since such a check is possible, that's definitely a merge-stopper
IMO</quote>. Robert replied:</p>

<quote who="Robert Love">

<p>First, I am not asking that Linus merge this.  Everyone needs to relax.</p>

<p>Second, we don't know a DMI-based solution will work. I'll check it out.</p>

</quote>

</section>

<section
  title="Linux 2.6.12.6 Released"
  subject="Linux 2.6.12.6"
  archive="http://groups.google.com/group/fa.linux.kernel/msg/3459a13ac33465b9?hl=en"
  posts="2"
  startdate="29 Aug 2005 10:04:18 -0800"
  enddate="29 Aug 2005 10:05:42 -0800"
>
<topic>Capabilities</topic>
<topic>Compression</topic>

<mention>Patrick McHardy</mention>
<mention>Chris Wright:</mention>
<mention>Bhavesh P. Davda</mention>
<mention>Linus Torvalds</mention>

<p>Chris Wright announced Linux 2.6.12.6, saying:</p>

<quote who="Chris Wright">

<p>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.</p>

<p>The diffstat and short summary of the fixes are below.</p>

<p>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.</p>

<p>The updated 2.6.12.y git tree can be found at:<br />
        rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git<br />
and can be browsed at the normal kernel.org git web browser:<br />
        <a href="http://www.kernel.org/git/">www.kernel.org/git/</a></p>

<p>Summary of changes from v2.6.12.5 to v2.6.12.6<br />
==============================================</p>

<p>Bhavesh P. Davda:
  NPTL signal delivery deadlock fix</p>

<p>Chris Wright:<br />
  Linux 2.6.12.6</p>

<p>Herbert Xu:<br />
  Restrict socket policy loading to CAP_NET_ADMIN - CAN-2005-2555</p>

<p>Jan Blunck:<br />
  sg.c: fix a memory leak in devices seq_file implementation (2nd)</p>

<p>lepton:<br />
  fix gl_skb/skb type error in genelink driver in usbnet</p>

<p>Linus Torvalds:<br />
  Revert unnecessary zlib_inflate/inftrees.c fix</p>

<p>Patrick McHardy:<br />
  Fix DST leak in icmp_push_reply()<br />
  Fix SKB leak in ip6_input_finish()</p>

</quote>

</section>

<section
  title="MPC8xx PCMCIA Driver Wends Its Way Into 2.6"
  subject="[PATCH] MPC8xx PCMCIA driver"
  archive="http://groups.google.com/group/linux.kernel/msg/d070fe67b5c62a26?hl=en"
  posts="10"
  startdate="29 Aug 2005 18:48:40 -0800"
  enddate="01 Sep 2005 06:51:56 -0800"
>
<topic>Forward Port</topic>

<p>Marcelo Tosatti said:</p>

<quote who="Marcelo Tosatti">

<p>Here goes the 8xx PCMCIA driver, originally written by Magnus Damm,
with several improvements and fixes.</p>

<p>The driver was merged in v2.4 but never forward ported to v2.6.</p>

<p>Please review, comments are welcome (including aesthetic enhancements).</p>

</quote>

<p>Magnus Damm replied at one point:</p>

<quote who="Magnus Damm">

<p>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.</p>

<p>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.</p>

</quote>

</section>

<section
  title="Monitoring Kernel Use Among Consenting Users"
  subject="KLive: Linux Kernel Live Usage Monitor"
  archive="http://groups.google.com/group/fa.linux.kernel/msg/a364b364ee8a0d28?hl=en"
  posts="33"
  startdate="29 Aug 2005 19:09:59 -0800"
  enddate="01 Sep 2005 07:23:44 -0800"
>
<topic>Bug Tracking</topic>
<topic>Disks: IDE</topic>

<p>Andrea Arcangeli said:</p>

<quote who="Andrea Arcangeli">

<p>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.</p>

<p>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 ;).</p>

<p>All the details can be found in the project website:</p>

<p><a href="http://klive.cpushare.com/">http://klive.cpushare.com/</a></p>

<p>Full source (server included) is here:</p>

<p><a href="http://klive.cpushare.com/downloads/klive-0.0.tar.bz2">http://klive.cpushare.com/downloads/klive-0.0.tar.bz2</a></p>

<p>To run the client:</p>

<p>        wget http://klive.cpushare.com/klive.tac</p>

<p>Then at every boot (like in /etc/init.d/boot.local):</p>

<p>        twistd -oy klive.tac</p>

<p>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.</p>

</quote>

<p>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, <quote who="Alan Cox">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')</quote>. And Sven Ladegast agreed, <quote who="Sven Ladegast">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.</quote> And
Alan added, <quote who="Alan Cox">We don't need personally identifiable data
(email, name, ip address etc.) What to do with it will be most interesting
indeed.</quote></p>

</section>

</kc>

