<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/um/include, branch v2.6.20</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>[PATCH] uml: fix net_kern workqueue abuse</title>
<updated>2006-12-13T17:05:47+00:00</updated>
<author>
<name>Peter Zijlstra</name>
<email>a.p.zijlstra@chello.nl</email>
</author>
<published>2006-12-13T08:33:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=eff3b634d9a0cccb6ca8b431819fa415f10804dc'/>
<id>eff3b634d9a0cccb6ca8b431819fa415f10804dc</id>
<content type='text'>
Fix up the work on stack and exit scope trouble by placing the work_struct
in the uml_net_private data.

Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Acked-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix up the work on stack and exit scope trouble by placing the work_struct
in the uml_net_private data.

Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Acked-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] tty: switch to ktermios</title>
<updated>2006-12-08T16:28:57+00:00</updated>
<author>
<name>Alan Cox</name>
<email>alan@lxorguk.ukuu.org.uk</email>
</author>
<published>2006-12-08T10:38:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=606d099cdd1080bbb50ea50dc52d98252f8f10a1'/>
<id>606d099cdd1080bbb50ea50dc52d98252f8f10a1</id>
<content type='text'>
This is the grungy swap all the occurrences in the right places patch that
goes with the updates.  At this point we have the same functionality as
before (except that sgttyb() returns speeds not zero) and are ready to
begin turning new stuff on providing nobody reports lots of bugs

If you are a tty driver author converting an out of tree driver the only
impact should be termios-&gt;ktermios name changes for the speed/property
setting functions from your upper layers.

If you are implementing your own TCGETS function before then your driver
was broken already and its about to get a whole lot more painful for you so
please fix it 8)

Also fill in c_ispeed/ospeed on init for most devices, although the current
code will do this for you anyway but I'd like eventually to lose that extra
paranoia

[akpm@osdl.org: bluetooth fix]
[mp3@de.ibm.com: sclp fix]
[mp3@de.ibm.com: warning fix for tty3270]
[hugh@veritas.com: fix tty_ioctl powerpc build]
[jdike@addtoit.com: uml: fix -&gt;set_termios declaration]
Signed-off-by: Alan Cox &lt;alan@redhat.com&gt;
Signed-off-by: Martin Peschke &lt;mp3@de.ibm.com&gt;
Acked-by: Peter Oberparleiter &lt;oberpar@de.ibm.com&gt;
Cc: Cornelia Huck &lt;cornelia.huck@de.ibm.com&gt;
Signed-off-by: Hugh Dickins &lt;hugh@veritas.com&gt;
Signed-off-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Cc: Paolo 'Blaisorblade' Giarrusso &lt;blaisorblade@yahoo.it&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is the grungy swap all the occurrences in the right places patch that
goes with the updates.  At this point we have the same functionality as
before (except that sgttyb() returns speeds not zero) and are ready to
begin turning new stuff on providing nobody reports lots of bugs

If you are a tty driver author converting an out of tree driver the only
impact should be termios-&gt;ktermios name changes for the speed/property
setting functions from your upper layers.

If you are implementing your own TCGETS function before then your driver
was broken already and its about to get a whole lot more painful for you so
please fix it 8)

Also fill in c_ispeed/ospeed on init for most devices, although the current
code will do this for you anyway but I'd like eventually to lose that extra
paranoia

[akpm@osdl.org: bluetooth fix]
[mp3@de.ibm.com: sclp fix]
[mp3@de.ibm.com: warning fix for tty3270]
[hugh@veritas.com: fix tty_ioctl powerpc build]
[jdike@addtoit.com: uml: fix -&gt;set_termios declaration]
Signed-off-by: Alan Cox &lt;alan@redhat.com&gt;
Signed-off-by: Martin Peschke &lt;mp3@de.ibm.com&gt;
Acked-by: Peter Oberparleiter &lt;oberpar@de.ibm.com&gt;
Cc: Cornelia Huck &lt;cornelia.huck@de.ibm.com&gt;
Signed-off-by: Hugh Dickins &lt;hugh@veritas.com&gt;
Signed-off-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Cc: Paolo 'Blaisorblade' Giarrusso &lt;blaisorblade@yahoo.it&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] uml: size register files correctly</title>
<updated>2006-12-07T16:39:29+00:00</updated>
<author>
<name>Jeff Dike</name>
<email>jdike@addtoit.com</email>
</author>
<published>2006-12-07T04:34:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e46962fdd28f8b30b465e507b657627aa4c1a409'/>
<id>e46962fdd28f8b30b465e507b657627aa4c1a409</id>
<content type='text'>
We were using the wrong symbol to size register files.

Signed-off-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Cc: Paolo 'Blaisorblade' Giarrusso &lt;blaisorblade@yahoo.it&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We were using the wrong symbol to size register files.

Signed-off-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Cc: Paolo 'Blaisorblade' Giarrusso &lt;blaisorblade@yahoo.it&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] uml: include asm/page.h in order to get PAGE_SHIFT</title>
<updated>2006-12-07T16:39:29+00:00</updated>
<author>
<name>Jeff Dike</name>
<email>jdike@addtoit.com</email>
</author>
<published>2006-12-07T04:34:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7b65fee21c6bff68711b48e0aa1cfd42b3198312'/>
<id>7b65fee21c6bff68711b48e0aa1cfd42b3198312</id>
<content type='text'>
Include the proper header to get a definition of PAGE_SHIFT.

Signed-off-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Cc: Paolo 'Blaisorblade' Giarrusso &lt;blaisorblade@yahoo.it&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Include the proper header to get a definition of PAGE_SHIFT.

Signed-off-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Cc: Paolo 'Blaisorblade' Giarrusso &lt;blaisorblade@yahoo.it&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] uml: workqueue build fix</title>
<updated>2006-12-07T16:39:20+00:00</updated>
<author>
<name>Andrew Morton</name>
<email>akpm@osdl.org</email>
</author>
<published>2006-12-07T04:31:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a2ce774096110ccc5c02cbdc05897d005fcd3db8'/>
<id>a2ce774096110ccc5c02cbdc05897d005fcd3db8</id>
<content type='text'>
  arch/um/drivers/chan_kern.c:643: error: conflicting types for 'chan_interrupt'
  arch/um/include/chan_kern.h:31: error: previous declaration of 'chan_interrupt'

Cc: David Howells &lt;dhowells@redhat.com&gt;
Cc: Jeff Dike &lt;jdike@addtoit.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
  arch/um/drivers/chan_kern.c:643: error: conflicting types for 'chan_interrupt'
  arch/um/include/chan_kern.h:31: error: previous declaration of 'chan_interrupt'

Cc: David Howells &lt;dhowells@redhat.com&gt;
Cc: Jeff Dike &lt;jdike@addtoit.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[NET]: UML checksum annotations and cleanups.</title>
<updated>2006-12-03T05:23:12+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2006-11-15T05:19:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=abf419b809bed2333267e4b23dd2b3b4f10da88c'/>
<id>abf419b809bed2333267e4b23dd2b3b4f10da88c</id>
<content type='text'>
* sanitize prototypes, annotate
* kill csum_partial_copy_fromuser
* kill shift-by-16 in checksum calculations
* ntohs-&gt;shift in checksum calculations

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&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>
* sanitize prototypes, annotate
* kill csum_partial_copy_fromuser
* kill shift-by-16 in checksum calculations
* ntohs-&gt;shift in checksum calculations

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] uml: make execvp safe for our usage</title>
<updated>2006-11-25T21:28:34+00:00</updated>
<author>
<name>Paolo 'Blaisorblade' Giarrusso</name>
<email>blaisorblade@yahoo.it</email>
</author>
<published>2006-11-25T19:09:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5d48545e5e88ab7a27ba6a5cb1e8fff617754b61'/>
<id>5d48545e5e88ab7a27ba6a5cb1e8fff617754b61</id>
<content type='text'>
Reimplement execvp for our purposes - after we call fork() it is fundamentally
unsafe to use the kernel allocator - current is not valid there.  So we simply
pass to our modified execvp() a preallocated buffer.  This fixes a real bug
and works very well in testing (I've seen indirectly warning messages from the
forked thread - they went on the pipe connected to its stdout and where read
as a number by UML, when calling read_output().  I verified the obtained
number corresponded to "BUG:").

The added use of __cant_sleep() is not a new bug since __cant_sleep() is
already used in the same function - passing an atomicity parameter would be
better but it would require huge change, stating that this function must not
be called in atomic context and can sleep is a better idea (will make sure of
this gradually).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso &lt;blaisorblade@yahoo.it&gt;
Acked-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reimplement execvp for our purposes - after we call fork() it is fundamentally
unsafe to use the kernel allocator - current is not valid there.  So we simply
pass to our modified execvp() a preallocated buffer.  This fixes a real bug
and works very well in testing (I've seen indirectly warning messages from the
forked thread - they went on the pipe connected to its stdout and where read
as a number by UML, when calling read_output().  I verified the obtained
number corresponded to "BUG:").

The added use of __cant_sleep() is not a new bug since __cant_sleep() is
already used in the same function - passing an atomicity parameter would be
better but it would require huge change, stating that this function must not
be called in atomic context and can sleep is a better idea (will make sure of
this gradually).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso &lt;blaisorblade@yahoo.it&gt;
Acked-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] uml: fix I/O hang</title>
<updated>2006-11-03T20:27:58+00:00</updated>
<author>
<name>Jeff Dike</name>
<email>jdike@addtoit.com</email>
</author>
<published>2006-11-03T06:07:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=53b173327d283b9bdbfb0c3b6de6f0eb197819d6'/>
<id>53b173327d283b9bdbfb0c3b6de6f0eb197819d6</id>
<content type='text'>
Fix a UML hang in which everything would just stop until some I/O happened
- a ping, someone whacking the keyboard - at which point everything would
start up again as though nothing had happened.

The cause was gcc reordering some code which absolutely needed to be
executed in the order in the source.  When unblock_signals switches signals
from off to on, it needs to see if any interrupts had happened in the
critical section.  The interrupt handlers check signals_enabled - if it is
zero, then the handler adds a bit to the "pending" bitmask and returns.
unblock_signals checks this mask to see if any signals need to be
delivered.

The crucial part is this:
	signals_enabled = 1;
	save_pending = pending;
	if(save_pending == 0)
		return;
	pending = 0;

In order to avoid an interrupt arriving between reading pending and setting
it to zero, in which case, the record of the interrupt would be erased,
signals are enabled.

What happened was that gcc reordered this so that 'save_pending = pending'
came before 'signals_enabled = 1', creating a one-instruction window within
which an interrupt could arrive, set its bit in pending, and have it be
immediately erased.

When the I/O workload is purely disk-based, the loss of a block device
interrupt stops the entire I/O system because the next block request will
wait for the current one to finish.  Thus the system hangs until something
else causes some I/O to arrive, such as a network packet or console input.

The fix to this particular problem is a memory barrier between enabling
signals and reading the pending signal mask.  An xchg would also probably
work.

Looking over this code for similar problems led me to do a few more
things:

- make signals_enabled and pending volatile so that they don't get cached
  in registers

- add an mb() to the return paths of block_signals and unblock_signals so
  that the modification of signals_enabled doesn't get shuffled into the
  caller in the event that these are inlined in the future.

Signed-off-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Cc: Paolo 'Blaisorblade' Giarrusso &lt;blaisorblade@yahoo.it&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix a UML hang in which everything would just stop until some I/O happened
- a ping, someone whacking the keyboard - at which point everything would
start up again as though nothing had happened.

The cause was gcc reordering some code which absolutely needed to be
executed in the order in the source.  When unblock_signals switches signals
from off to on, it needs to see if any interrupts had happened in the
critical section.  The interrupt handlers check signals_enabled - if it is
zero, then the handler adds a bit to the "pending" bitmask and returns.
unblock_signals checks this mask to see if any signals need to be
delivered.

The crucial part is this:
	signals_enabled = 1;
	save_pending = pending;
	if(save_pending == 0)
		return;
	pending = 0;

In order to avoid an interrupt arriving between reading pending and setting
it to zero, in which case, the record of the interrupt would be erased,
signals are enabled.

What happened was that gcc reordered this so that 'save_pending = pending'
came before 'signals_enabled = 1', creating a one-instruction window within
which an interrupt could arrive, set its bit in pending, and have it be
immediately erased.

When the I/O workload is purely disk-based, the loss of a block device
interrupt stops the entire I/O system because the next block request will
wait for the current one to finish.  Thus the system hangs until something
else causes some I/O to arrive, such as a network packet or console input.

The fix to this particular problem is a memory barrier between enabling
signals and reading the pending signal mask.  An xchg would also probably
work.

Looking over this code for similar problems led me to do a few more
things:

- make signals_enabled and pending volatile so that they don't get cached
  in registers

- add an mb() to the return paths of block_signals and unblock_signals so
  that the modification of signals_enabled doesn't get shuffled into the
  caller in the event that these are inlined in the future.

Signed-off-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Cc: Paolo 'Blaisorblade' Giarrusso &lt;blaisorblade@yahoo.it&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] uml ubd driver: various little changes</title>
<updated>2006-10-31T16:07:00+00:00</updated>
<author>
<name>Paolo 'Blaisorblade' Giarrusso</name>
<email>blaisorblade@yahoo.it</email>
</author>
<published>2006-10-31T06:07:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d8d7c28ec0b50ac57ddc909ae6eca1519473f300'/>
<id>d8d7c28ec0b50ac57ddc909ae6eca1519473f300</id>
<content type='text'>
Fix a small memory leak in ubd_config, and clearify the confusion which lead
to it.

Then, some little changes not affecting operations -
* move init functions together,
* add a comment about a potential problem in case of some evolution in the block layer,
* mark all initcalls as static __init functions
* mark an used once little function as inline
* document that mconsole methods are all called in process context (was
  triggered when checking ubd mconsole methods).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso &lt;blaisorblade@yahoo.it&gt;
Cc: Jeff Dike &lt;jdike@addtoit.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix a small memory leak in ubd_config, and clearify the confusion which lead
to it.

Then, some little changes not affecting operations -
* move init functions together,
* add a comment about a potential problem in case of some evolution in the block layer,
* mark all initcalls as static __init functions
* mark an used once little function as inline
* document that mconsole methods are all called in process context (was
  triggered when checking ubd mconsole methods).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso &lt;blaisorblade@yahoo.it&gt;
Cc: Jeff Dike &lt;jdike@addtoit.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] uml: mconsole fixes</title>
<updated>2006-10-25T05:01:10+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@ftp.linux.org.uk</email>
</author>
<published>2006-10-24T10:15:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3a51237dc11efe283b40ea0248f4e26ab935dbd1'/>
<id>3a51237dc11efe283b40ea0248f4e26ab935dbd1</id>
<content type='text'>
 * when we have stop/sysrq/go, we get pt_regs of whatever executes
   mc_work_proc().  Would be better to see what we had at the time of
   interrupt that got us stop.

 * stop/stop/stop.....  will give stack overflow.  Shouldn't allow stop
   from mconsole_stop().

 * stop/stop/go leaves us inside mconsole_stop() with
	os_set_fd_block(req-&gt;originating_fd, 0);
	reactivate_fd(req-&gt;originating_fd, MCONSOLE_IRQ);
   just done by nested mconsole_stop().  Ditto.

 * once we'd seen stop, there's a period when INTR commands are executed
   out of order (as they should; we might have the things stuck badly
   enough to never reach mconsole_stop(), but still not badly enough to
   block mconsole_interrupt(); in that situation we _want_ things like
   "cad" to be executed immediately).  Once we enter monsole_stop(), all
   INTR commands will be executed in order, mixed with PROC ones.  We'd
   better let user see that such change of behaviour has happened.
   (Suggested by lennert).

 * stack footprint of monsole_interrupt() is an atrocity; AFAICS we can
   safely make struct mc_request req; static in function there.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Acked-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * when we have stop/sysrq/go, we get pt_regs of whatever executes
   mc_work_proc().  Would be better to see what we had at the time of
   interrupt that got us stop.

 * stop/stop/stop.....  will give stack overflow.  Shouldn't allow stop
   from mconsole_stop().

 * stop/stop/go leaves us inside mconsole_stop() with
	os_set_fd_block(req-&gt;originating_fd, 0);
	reactivate_fd(req-&gt;originating_fd, MCONSOLE_IRQ);
   just done by nested mconsole_stop().  Ditto.

 * once we'd seen stop, there's a period when INTR commands are executed
   out of order (as they should; we might have the things stuck badly
   enough to never reach mconsole_stop(), but still not badly enough to
   block mconsole_interrupt(); in that situation we _want_ things like
   "cad" to be executed immediately).  Once we enter monsole_stop(), all
   INTR commands will be executed in order, mixed with PROC ones.  We'd
   better let user see that such change of behaviour has happened.
   (Suggested by lennert).

 * stack footprint of monsole_interrupt() is an atrocity; AFAICS we can
   safely make struct mc_request req; static in function there.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Acked-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
