<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux-stable.git/drivers/net/pcnet32.c, branch linux-2.6.14.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-2.6.14.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-2.6.14.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/'/>
<updated>2005-06-28T22:25:31+00:00</updated>
<entry>
<title>[NET]: Remove gratuitous use of skb-&gt;tail in network drivers.</title>
<updated>2005-06-28T22:25:31+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2005-06-28T22:25:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=689be43945e9ca7dd704522e55af1b8a73a994d3'/>
<id>urn:sha1:689be43945e9ca7dd704522e55af1b8a73a994d3</id>
<content type='text'>
Many drivers use skb-&gt;tail unnecessarily.

In these situations, the code roughly looks like:

	dev = dev_alloc_skb(...);

	[optional] skb_reserve(skb, ...);

	... skb-&gt;tail ...

But even if the skb_reserve() happens, skb-&gt;data equals
skb-&gt;tail.  So it doesn't make any sense to use anything
other than skb-&gt;data in these cases.

Another case was the s2io.c driver directly mucking with
the skb-&gt;data and skb-&gt;tail pointers.  It really just wanted
to do an skb_reserve(), so that's what the code was changed
to do instead.

Another reason I'm making this change as it allows some SKB
cleanups I have planned simpler to merge.  In those cleanups,
skb-&gt;head, skb-&gt;tail, and skb-&gt;end pointers are removed, and
replaced with skb-&gt;head_room and skb-&gt;tail_room integers.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Acked-by: Jeff Garzik &lt;jgarzik@pobox.com&gt;
</content>
</entry>
<entry>
<title>[PATCH] net/pcnet32: replace schedule_timeout() with msleep_interruptible()</title>
<updated>2005-06-27T03:48:37+00:00</updated>
<author>
<name>Nishanth Aravamudan</name>
<email>nacc@us.ibm.com</email>
</author>
<published>2005-06-20T21:54:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=f17697a37ccd2128f37250d2e7715c59931dc458'/>
<id>urn:sha1:f17697a37ccd2128f37250d2e7715c59931dc458</id>
<content type='text'>
Use msleep_interruptible() instead of schedule_timeout() to
guarantee the task delays as expected.

Signed-off-by: Nishanth Aravamudan &lt;nacc@us.ibm.com&gt;
Signed-off-by: Maximilian Attems &lt;janitor@sternwelten.at&gt;
Signed-off-by: Domen Puncer &lt;domen@coderock.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] pcnet32: fix resource leak with loopback test</title>
<updated>2005-05-15T22:22:29+00:00</updated>
<author>
<name>Don Fry</name>
<email>brazilnut@us.ibm.com</email>
</author>
<published>2005-04-29T21:51:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=1bcd315362e215a72b56d1330bbf32f1c74eefb5'/>
<id>urn:sha1:1bcd315362e215a72b56d1330bbf32f1c74eefb5</id>
<content type='text'>
When running the loopback test, resources are not properly released on
completion.  This patch frees all transmit resources after running the
loopback test.  Tested on ia32 and ppc64 hardware.

Signed-off-by: Don Fry &lt;brazilnut@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>Linux-2.6.12-rc2</title>
<updated>2005-04-16T22:20:36+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@ppc970.osdl.org</email>
</author>
<published>2005-04-16T22:20:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2'/>
<id>urn:sha1:1da177e4c3f41524e886b7f1b8a0c1fc7321cac2</id>
<content type='text'>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
</content>
</entry>
</feed>
