Re: [PATCH 0/8] aoe: miscellaneous fixes follow-up recent patch submissions
On Nov 28, 2012, at 6:42 PM, Andrew Morton wrote: > On Wed, 21 Nov 2012 19:52:41 -0500 > Ed Cashin wrote: > >> This patch series applies to today's linux-next/akpm, commit >> d3faae60d84f586ff8937b77c8476bca1b5f8ec6. >> >> Ed L. Cashin (8): >> aoe: copy fallback timing information on destination failover >> aoe: remove vestigial request queue allocation >> aoe: increase default cap on outstanding AoE commands in the network >> aoe: cleanup: correct comment for aoetgt nout >> aoe: remove call to request handler from I/O completion >> aoe: make error messages more specific in static minor allocation >> aoe: initialize sysminor to avoid compiler warning >> aoe: return real minor number for static minors > > This series didn't contain your usual > aoe-update-driver-internal-version-number-to-xx.patch That's true, yes. This was a bunch of fixups to 64+. I suppose I could have called it "64+1" or something, but more patches are coming, so I wasn't sure it was worth it. Thanks for mentioning it. -- Ed Cashin ecas...@coraid.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] aoe: miscellaneous fixes follow-up recent patch submissions
On Wed, 21 Nov 2012 19:52:41 -0500 Ed Cashin wrote: > This patch series applies to today's linux-next/akpm, commit > d3faae60d84f586ff8937b77c8476bca1b5f8ec6. > > Ed L. Cashin (8): > aoe: copy fallback timing information on destination failover > aoe: remove vestigial request queue allocation > aoe: increase default cap on outstanding AoE commands in the network > aoe: cleanup: correct comment for aoetgt nout > aoe: remove call to request handler from I/O completion > aoe: make error messages more specific in static minor allocation > aoe: initialize sysminor to avoid compiler warning > aoe: return real minor number for static minors This series didn't contain your usual aoe-update-driver-internal-version-number-to-xx.patch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] aoe: miscellaneous fixes follow-up recent patch submissions
On Wed, 21 Nov 2012 19:52:41 -0500 Ed Cashin ecas...@coraid.com wrote: This patch series applies to today's linux-next/akpm, commit d3faae60d84f586ff8937b77c8476bca1b5f8ec6. Ed L. Cashin (8): aoe: copy fallback timing information on destination failover aoe: remove vestigial request queue allocation aoe: increase default cap on outstanding AoE commands in the network aoe: cleanup: correct comment for aoetgt nout aoe: remove call to request handler from I/O completion aoe: make error messages more specific in static minor allocation aoe: initialize sysminor to avoid compiler warning aoe: return real minor number for static minors This series didn't contain your usual aoe-update-driver-internal-version-number-to-xx.patch -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] aoe: miscellaneous fixes follow-up recent patch submissions
On Nov 28, 2012, at 6:42 PM, Andrew Morton wrote: On Wed, 21 Nov 2012 19:52:41 -0500 Ed Cashin ecas...@coraid.com wrote: This patch series applies to today's linux-next/akpm, commit d3faae60d84f586ff8937b77c8476bca1b5f8ec6. Ed L. Cashin (8): aoe: copy fallback timing information on destination failover aoe: remove vestigial request queue allocation aoe: increase default cap on outstanding AoE commands in the network aoe: cleanup: correct comment for aoetgt nout aoe: remove call to request handler from I/O completion aoe: make error messages more specific in static minor allocation aoe: initialize sysminor to avoid compiler warning aoe: return real minor number for static minors This series didn't contain your usual aoe-update-driver-internal-version-number-to-xx.patch That's true, yes. This was a bunch of fixups to 64+. I suppose I could have called it 64+1 or something, but more patches are coming, so I wasn't sure it was worth it. Thanks for mentioning it. -- Ed Cashin ecas...@coraid.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/8] aoe: miscellaneous fixes follow-up recent patch submissions
This patch series applies to today's linux-next/akpm, commit d3faae60d84f586ff8937b77c8476bca1b5f8ec6. Ed L. Cashin (8): aoe: copy fallback timing information on destination failover aoe: remove vestigial request queue allocation aoe: increase default cap on outstanding AoE commands in the network aoe: cleanup: correct comment for aoetgt nout aoe: remove call to request handler from I/O completion aoe: make error messages more specific in static minor allocation aoe: initialize sysminor to avoid compiler warning aoe: return real minor number for static minors drivers/block/aoe/aoe.h|2 +- drivers/block/aoe/aoeblk.c | 17 - drivers/block/aoe/aoecmd.c |5 ++--- drivers/block/aoe/aoedev.c | 35 ++- 4 files changed, 29 insertions(+), 30 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/8] aoe: miscellaneous fixes follow-up recent patch submissions
This patch series applies to today's linux-next/akpm, commit d3faae60d84f586ff8937b77c8476bca1b5f8ec6. Ed L. Cashin (8): aoe: copy fallback timing information on destination failover aoe: remove vestigial request queue allocation aoe: increase default cap on outstanding AoE commands in the network aoe: cleanup: correct comment for aoetgt nout aoe: remove call to request handler from I/O completion aoe: make error messages more specific in static minor allocation aoe: initialize sysminor to avoid compiler warning aoe: return real minor number for static minors drivers/block/aoe/aoe.h|2 +- drivers/block/aoe/aoeblk.c | 17 - drivers/block/aoe/aoecmd.c |5 ++--- drivers/block/aoe/aoedev.c | 35 ++- 4 files changed, 29 insertions(+), 30 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
On Tue, 6 Mar 2001, Andrew Morton wrote: > With respect, Rik. You haven't finished the 2.4 VM yet. > > It needs better design description. > Could you please take the time to raise a commentary patch > which describes the underlying design intent? OK, I'll go work on this... You are right, this is an extremely important thing. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
Rik van Riel wrote: > > On Tue, 6 Mar 2001, Alan Cox wrote: > > > I'm getting a notable increase in people sending me patches that > > do major things and should be 2.5 stuff. Please if you want to > > rewrite the VM completely, redesign the scsi layer and the like > > wait until 2.5. > > VM folks can post their patches to [EMAIL PROTECTED], where > we can play with things until 2.5 is forked. > With respect, Rik. You haven't finished the 2.4 VM yet. It needs better design description. I've been reading through it lately, and in some parts it is very, very hard to go backwards from the implementation to the designer's intent. Let's take just one line: count = inactive_shortage() + free_shortage(); That expands to, approximately, sometimes: inactive_shortage(): freepages.high + inactive_target - nr_free_pages() - nr_inactive_clean_pages() - nr_inactive_dirty_pages; plus free_shortage(): (freepages.high + inactive_target / 3) - (nr_free_pages() + nr_inactive_clean_pages()) IOW: 2 * freepages.high + 1.33*(min((memory_pressure >> INACTIVE_SHIFT), (num_physpages / 4))) - 2 * nr_free_pages() - 2 * nr_inactive_clean_pages() - nr_inactive_dirty_pages That's not a thing which just leaps out at me and shouts "ah-ha!" :) Across the lifetime of 2.4, other people are going to need to understand this stuff. To be able to analyse and even predict how the VM dynamics will change with varying tuning, varying workload and varying platform characteristics. There *is* a fair quantity of good design description in there, but there are gaps. Could you please take the time to raise a commentary patch which describes the underlying design intent? I'd strongly recommend *against* some offstream document (it doesn't get updated) or API documentation (usually lame and useless). Inline description is much more useful and better maintained. Thanks - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
Rik van Riel wrote: > On Tue, 6 Mar 2001, Kurt Garloff wrote: > > On Tue, Mar 06, 2001 at 02:22:58PM -0300, Rik van Riel wrote: > > > probably even out of linux-kernel ... > > > > No. I want to see experimental stuff on l-k. That's what it's meant for. > > Putting the experimental stuff which isn't on l-k at the > moment would probably triple the volume of this list, if > not more ... > > I'm pretty sure most people already find l-k traffic too > heavy to keep up. If you want to read all the experimental > stuff of all the subsystems, why not subscribe to the > mailing lists of those subsystems ? Every patch doesn't need to go to lkml, but keeping linux-kernel folks updated on experimental issues is always IMHO a good idea. Otherwise, interested folks who don't have time to find out about and subscribe to 1000 other lists are kept informed. Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
On Tue, 6 Mar 2001, Kurt Garloff wrote: > On Tue, Mar 06, 2001 at 02:22:58PM -0300, Rik van Riel wrote: > > I agree with Alan that we should keep all experimental stuff > > out of 2.4, > > Depends on the impact. Experimental stuff in MM, FS, ... [snip] > But, that's probably what you meant. *nod* > > probably even out of linux-kernel ... > > No. I want to see experimental stuff on l-k. That's what it's meant for. Putting the experimental stuff which isn't on l-k at the moment would probably triple the volume of this list, if not more ... I'm pretty sure most people already find l-k traffic too heavy to keep up. If you want to read all the experimental stuff of all the subsystems, why not subscribe to the mailing lists of those subsystems ? regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
On Tue, Mar 06, 2001 at 02:22:58PM -0300, Rik van Riel wrote: > I agree with Alan that we should keep all experimental stuff > out of 2.4, Depends on the impact. Experimental stuff in MM, FS, ... things is something which we don't want. If somebody writes a new driver for a device which was not supported before, we may want to add it to the kernel to get it tested and improved. But, that's probably what you meant. > probably even out of linux-kernel ... No. I want to see experimental stuff on l-k. That's what it's meant for. Regards, -- Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security PGP signature
Re: Patch submissions
On Tue, 6 Mar 2001, Lars Marowsky-Bree wrote: > On 2001-03-06T16:56:32, >Alan Cox <[EMAIL PROTECTED]> said: > > > I'm getting a notable increase in people sending me patches that do major > > things and should be 2.5 stuff. Please if you want to rewrite the VM completely, > > redesign the scsi layer and the like wait until 2.5. > > When will 2.5 be forked? > > If anyone wants to redesign the SCSI layer, by all means, DO NOT > STOP HIM! ;-) If somebody is able to redesign the SCSI layer, I'm *sure* that person will be able to maintain a separate patch for some time ... regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
On Tue, 6 Mar 2001, Alan Cox wrote: > I'm getting a notable increase in people sending me patches that > do major things and should be 2.5 stuff. Please if you want to > rewrite the VM completely, redesign the scsi layer and the like > wait until 2.5. VM folks can post their patches to [EMAIL PROTECTED], where we can play with things until 2.5 is forked. I agree with Alan that we should keep all experimental stuff out of 2.4, probably even out of linux-kernel ... regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
On 2001-03-06T16:56:32, Alan Cox <[EMAIL PROTECTED]> said: > I'm getting a notable increase in people sending me patches that do major > things and should be 2.5 stuff. Please if you want to rewrite the VM completely, > redesign the scsi layer and the like wait until 2.5. When will 2.5 be forked? If anyone wants to redesign the SCSI layer, by all means, DO NOT STOP HIM! ;-) Sincerely, Lars Marowsky-Brée <[EMAIL PROTECTED]> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch submissions
I'm getting a notable increase in people sending me patches that do major things and should be 2.5 stuff. Please if you want to rewrite the VM completely, redesign the scsi layer and the like wait until 2.5. Right now I'm only collecting patches that are driver bugfix/updates, arch specific updates/fixes or bugfixes (not feature adds) for the core kernel code. Anything else goes in the bitbucket - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch submissions
I'm getting a notable increase in people sending me patches that do major things and should be 2.5 stuff. Please if you want to rewrite the VM completely, redesign the scsi layer and the like wait until 2.5. Right now I'm only collecting patches that are driver bugfix/updates, arch specific updates/fixes or bugfixes (not feature adds) for the core kernel code. Anything else goes in the bitbucket - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
On 2001-03-06T16:56:32, Alan Cox [EMAIL PROTECTED] said: I'm getting a notable increase in people sending me patches that do major things and should be 2.5 stuff. Please if you want to rewrite the VM completely, redesign the scsi layer and the like wait until 2.5. When will 2.5 be forked? If anyone wants to redesign the SCSI layer, by all means, DO NOT STOP HIM! ;-) Sincerely, Lars Marowsky-Bre [EMAIL PROTECTED] -- Perfection is our goal, excellence will be tolerated. -- J. Yahl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
On Tue, 6 Mar 2001, Alan Cox wrote: I'm getting a notable increase in people sending me patches that do major things and should be 2.5 stuff. Please if you want to rewrite the VM completely, redesign the scsi layer and the like wait until 2.5. VM folks can post their patches to [EMAIL PROTECTED], where we can play with things until 2.5 is forked. I agree with Alan that we should keep all experimental stuff out of 2.4, probably even out of linux-kernel ... regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
On Tue, 6 Mar 2001, Lars Marowsky-Bree wrote: On 2001-03-06T16:56:32, Alan Cox [EMAIL PROTECTED] said: I'm getting a notable increase in people sending me patches that do major things and should be 2.5 stuff. Please if you want to rewrite the VM completely, redesign the scsi layer and the like wait until 2.5. When will 2.5 be forked? If anyone wants to redesign the SCSI layer, by all means, DO NOT STOP HIM! ;-) If somebody is able to redesign the SCSI layer, I'm *sure* that person will be able to maintain a separate patch for some time ... regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
On Tue, Mar 06, 2001 at 02:22:58PM -0300, Rik van Riel wrote: I agree with Alan that we should keep all experimental stuff out of 2.4, Depends on the impact. Experimental stuff in MM, FS, ... things is something which we don't want. If somebody writes a new driver for a device which was not supported before, we may want to add it to the kernel to get it tested and improved. But, that's probably what you meant. probably even out of linux-kernel ... No. I want to see experimental stuff on l-k. That's what it's meant for. Regards, -- Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security PGP signature
Re: Patch submissions
On Tue, 6 Mar 2001, Kurt Garloff wrote: On Tue, Mar 06, 2001 at 02:22:58PM -0300, Rik van Riel wrote: I agree with Alan that we should keep all experimental stuff out of 2.4, Depends on the impact. Experimental stuff in MM, FS, ... [snip] But, that's probably what you meant. *nod* probably even out of linux-kernel ... No. I want to see experimental stuff on l-k. That's what it's meant for. Putting the experimental stuff which isn't on l-k at the moment would probably triple the volume of this list, if not more ... I'm pretty sure most people already find l-k traffic too heavy to keep up. If you want to read all the experimental stuff of all the subsystems, why not subscribe to the mailing lists of those subsystems ? regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
Rik van Riel wrote: On Tue, 6 Mar 2001, Kurt Garloff wrote: On Tue, Mar 06, 2001 at 02:22:58PM -0300, Rik van Riel wrote: probably even out of linux-kernel ... No. I want to see experimental stuff on l-k. That's what it's meant for. Putting the experimental stuff which isn't on l-k at the moment would probably triple the volume of this list, if not more ... I'm pretty sure most people already find l-k traffic too heavy to keep up. If you want to read all the experimental stuff of all the subsystems, why not subscribe to the mailing lists of those subsystems ? Every patch doesn't need to go to lkml, but keeping linux-kernel folks updated on experimental issues is always IMHO a good idea. Otherwise, interested folks who don't have time to find out about and subscribe to 1000 other lists are kept informed. Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
Rik van Riel wrote: On Tue, 6 Mar 2001, Alan Cox wrote: I'm getting a notable increase in people sending me patches that do major things and should be 2.5 stuff. Please if you want to rewrite the VM completely, redesign the scsi layer and the like wait until 2.5. VM folks can post their patches to [EMAIL PROTECTED], where we can play with things until 2.5 is forked. With respect, Rik. You haven't finished the 2.4 VM yet. It needs better design description. I've been reading through it lately, and in some parts it is very, very hard to go backwards from the implementation to the designer's intent. Let's take just one line: count = inactive_shortage() + free_shortage(); That expands to, approximately, sometimes: inactive_shortage(): freepages.high + inactive_target - nr_free_pages() - nr_inactive_clean_pages() - nr_inactive_dirty_pages; plus free_shortage(): (freepages.high + inactive_target / 3) - (nr_free_pages() + nr_inactive_clean_pages()) IOW: 2 * freepages.high + 1.33*(min((memory_pressure INACTIVE_SHIFT), (num_physpages / 4))) - 2 * nr_free_pages() - 2 * nr_inactive_clean_pages() - nr_inactive_dirty_pages That's not a thing which just leaps out at me and shouts "ah-ha!" :) Across the lifetime of 2.4, other people are going to need to understand this stuff. To be able to analyse and even predict how the VM dynamics will change with varying tuning, varying workload and varying platform characteristics. There *is* a fair quantity of good design description in there, but there are gaps. Could you please take the time to raise a commentary patch which describes the underlying design intent? I'd strongly recommend *against* some offstream document (it doesn't get updated) or API documentation (usually lame and useless). Inline description is much more useful and better maintained. Thanks - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
On Tue, 6 Mar 2001, Andrew Morton wrote: With respect, Rik. You haven't finished the 2.4 VM yet. It needs better design description. Could you please take the time to raise a commentary patch which describes the underlying design intent? OK, I'll go work on this... You are right, this is an extremely important thing. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
