linux-toradex.git/arch/um/drivers/Makefile, branch v2.6.19.2 Linux kernel for Apalis and Colibri modules [PATCH] uml: revert block driver use of host AIO 2005-10-12T15:22:26+00:00 Jeff Dike jdike@addtoit.com 2005-10-11T03:10:32+00:00 91acb21f084aa244f26839406ae7ed8aa3668058 The patch to use host AIO support that I submitted early after 2.6.13 exposed some problems in the block driver. I have fixes for these, but am not comfortable putting them into 2.6.14 at this late date. So, this patch reverts the use of host AIO. I will resubmit the original patch, plus fixes to the driver after 2.6.14 in order to get a reasonable amount of testing before they're exposed to the general public. Signed-off-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
The patch to use host AIO support that I submitted early after 2.6.13 exposed
some problems in the block driver.  I have fixes for these, but am not
comfortable putting them into 2.6.14 at this late date.  So, this patch reverts
the use of host AIO.

I will resubmit the original patch, plus fixes to the driver after 2.6.14
in order to get a reasonable amount of testing before they're exposed to
the general public.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] uml: add host AIO support to block driver 2005-09-05T07:06:23+00:00 Jeff Dike jdike@addtoit.com 2005-09-03T22:57:46+00:00 09ace81c1d737bcbb2423db235ac980cac4d5de9 This adds AIO support to the ubd driver. The driver breaks a struct request into IO requests to the host, based on the hardware segments in the request and on any COW blocks covered by the request. The ubd IO thread is gone, since there is now an equivalent thread in the AIO module. There is provision for multiple outstanding requests now. Requests aren't retired until all pieces of it have been completed. The AIO requests have a shared count, which is decremented as IO operations come in until it reaches 0. This can be possibly moved to the request struct - haven't looked at this yet. Signed-off-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
This adds AIO support to the ubd driver.

The driver breaks a struct request into IO requests to the host, based on the
hardware segments in the request and on any COW blocks covered by the request.

The ubd IO thread is gone, since there is now an equivalent thread in the AIO
module.

There is provision for multiple outstanding requests now.  Requests aren't
retired until all pieces of it have been completed.  The AIO requests have a
shared count, which is decremented as IO operations come in until it reaches
0.  This can be possibly moved to the request struct - haven't looked at this
yet.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] uml: avoid unnecessary pcap rebuild 2005-07-29T04:46:03+00:00 Paolo 'Blaisorblade' Giarrusso blaisorblade@yahoo.it 2005-07-29T04:16:03+00:00 8afe07ce0003d4c63b7d76b6f28264503cb80d71 Just a Kbuild subtlety, not listing a target file inside targets causes it to be rebuilt each time, and as a consequence everything depending on it is rebuilt. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
Just a Kbuild subtlety, not listing a target file inside targets causes it
to be rebuilt each time, and as a consequence everything depending on it is
rebuilt.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] uml: reintroduce pcap support 2005-07-14T16:00:25+00:00 Paolo 'Blaisorblade' Giarrusso blaisorblade@yahoo.it 2005-07-14T07:33:41+00:00 ecc354a90af90a80dcaccc750f5f3e5e7c83112d The pcap support was not working because of some linking problems (expressing the construct in Kbuild was a bit difficult) and because there was no user request. Now that this has come back, here's the support. This has been tested and works on both 32 and 64-bit hosts, even when "cross-"building 32-bit binaries. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
The pcap support was not working because of some linking problems (expressing
the construct in Kbuild was a bit difficult) and because there was no user
request.  Now that this has come back, here's the support.

This has been tested and works on both 32 and 64-bit hosts, even when
"cross-"building 32-bit binaries.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] uml: slirp and slip driver cleanups and fixes 2005-06-14T03:58:43+00:00 Jeff Dike jdike@addtoit.com 2005-06-13T22:52:18+00:00 a3c77c67a443e631febf708bb0c376caede31657 This patch merges a lot of duplicated code in the slip and slirp drivers, abstracts out the slip protocol, and makes the slip driver work in 2.6. Signed-off-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
This patch merges a lot of duplicated code in the slip and slirp drivers,
abstracts out the slip protocol, and makes the slip driver work in 2.6.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Linux-2.6.12-rc2 2005-04-16T22:20:36+00:00 Linus Torvalds torvalds@ppc970.osdl.org 2005-04-16T22:20:36+00:00 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 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! 
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!