<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/net/ppp_generic.c, branch v2.6.13</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>[NET]: Transform skb_queue_len() binary tests into skb_queue_empty()</title>
<updated>2005-07-08T21:57:23+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2005-07-08T21:57:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b03efcfb2180289718991bb984044ce6c5b7d1b0'/>
<id>b03efcfb2180289718991bb984044ce6c5b7d1b0</id>
<content type='text'>
This is part of the grand scheme to eliminate the qlen
member of skb_queue_head, and subsequently remove the
'list' member of sk_buff.

Most users of skb_queue_len() want to know if the queue is
empty or not, and that's trivially done with skb_queue_empty()
which doesn't use the skb_queue_head-&gt;qlen member and instead
uses the queue list emptyness as the test.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is part of the grand scheme to eliminate the qlen
member of skb_queue_head, and subsequently remove the
'list' member of sk_buff.

Most users of skb_queue_len() want to know if the queue is
empty or not, and that's trivially done with skb_queue_empty()
which doesn't use the skb_queue_head-&gt;qlen member and instead
uses the queue list emptyness as the test.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] class: convert drivers/* to use the new class api instead of class_simple</title>
<updated>2005-06-20T22:15:09+00:00</updated>
<author>
<name>gregkh@suse.de</name>
<email>gregkh@suse.de</email>
</author>
<published>2005-03-23T18:01:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=56b2293595b2eb52cc2aa2baf92c6cfa8265f9d5'/>
<id>56b2293595b2eb52cc2aa2baf92c6cfa8265f9d5</id>
<content type='text'>
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>  [PATCH] PPP multilink fragmentation improvements</title>
<updated>2005-05-12T23:47:12+00:00</updated>
<author>
<name>Paul Mackerras</name>
<email>paulus@samba.org</email>
</author>
<published>2005-05-12T23:47:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=516cd15f1c0dd6eada3619915b113b4e5baccc7a'/>
<id>516cd15f1c0dd6eada3619915b113b4e5baccc7a</id>
<content type='text'>
  
  Here's a patch for -mm for now.  Not sure whose territory this falls
  in, so I'm sending it to everyone I can think of. :)
  
  Some time ago I did some experiments with using PPP multilink over
  largish numbers of channels (up to 32).  The TCP performance was
  woeful due to wildly fluctuating packet latencies, which turned out to
  be because we would sometimes split a packet across all 32 channels,
  and sometimes we would send a whole packet down a single channel.
  
  This patch fixes those problems by being a bit cleverer about how the
  packets are split across the available channels, and in particular, it
  waits until at least half of the channels can take another fragment
  before starting to split up the next packet.
  
  The patch also fixes a buglet in the multilink reconstruction code
  where it would discard incoming packets that had just the multilink
  header and no data.  Such packets are valid and shouldn't be
  discarded.
  
  Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
  Signed-off-by: Jeff Garzik &lt;jgarzik@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
  
  Here's a patch for -mm for now.  Not sure whose territory this falls
  in, so I'm sending it to everyone I can think of. :)
  
  Some time ago I did some experiments with using PPP multilink over
  largish numbers of channels (up to 32).  The TCP performance was
  woeful due to wildly fluctuating packet latencies, which turned out to
  be because we would sometimes split a packet across all 32 channels,
  and sometimes we would send a whole packet down a single channel.
  
  This patch fixes those problems by being a bit cleverer about how the
  packets are split across the available channels, and in particular, it
  waits until at least half of the channels can take another fragment
  before starting to split up the next packet.
  
  The patch also fixes a buglet in the multilink reconstruction code
  where it would discard incoming packets that had just the multilink
  header and no data.  Such packets are valid and shouldn't be
  discarded.
  
  Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
  Signed-off-by: Jeff Garzik &lt;jgarzik@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PPP]: remove redundant NULL pointer checks before kfree &amp; vfree</title>
<updated>2005-05-03T21:38:09+00:00</updated>
<author>
<name>Jesper Juhl</name>
<email>juhl-lkml@dif.dk</email>
</author>
<published>2005-05-03T21:38:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=96edf83c4e284c08584f97623f7c7f029759459e'/>
<id>96edf83c4e284c08584f97623f7c7f029759459e</id>
<content type='text'>
kfree() and vfree() can both deal with NULL pointers. This patch removes 
redundant NULL pointer checks from the ppp code in drivers/net/

Signed-off-by: Jesper Juhl &lt;juhl-lkml@dif.dk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
kfree() and vfree() can both deal with NULL pointers. This patch removes 
redundant NULL pointer checks from the ppp code in drivers/net/

Signed-off-by: Jesper Juhl &lt;juhl-lkml@dif.dk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</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.tavy.me/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2'/>
<id>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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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!
</pre>
</div>
</content>
</entry>
</feed>
