Re: [ltt-dev] [PATCH] nfs: add support for splice writes

Trond Myklebust wrote: On Mon, 2009-04-20 at 11:09 +0530, Suresh Jayaraman wrote: Hi Trond, Do you think this patch is OK? Can this be considered for merging? Thanks, diff --git a/fs/nfs/file.c b/fs/nfs/file.c index 90f292b..13d6a00 100644 --- a/fs/nfs/file.c +++ b/fs/nfs/file.c @@

Re: [ltt-dev] [PATCH] nfs: add support for splice writes

On Mon, 2009-04-20 at 11:09 +0530, Suresh Jayaraman wrote: Hi Trond, Do you think this patch is OK? Can this be considered for merging? Thanks, Masahiro Tamori wrote: Hello Suresh and Mathieu, 2009/4/2 Suresh Jayaraman sjayara...@suse.de: Mathieu Desnoyers wrote: * Suresh

Re: [ltt-dev] [PATCH] nfs: add support for splice writes

On Mon, 2009-04-20 at 18:08 +0530, Suresh Jayaraman wrote: Trond Myklebust wrote: On Mon, 2009-04-20 at 11:09 +0530, Suresh Jayaraman wrote: Hi Trond, Do you think this patch is OK? Can this be considered for merging? Thanks, diff --git a/fs/nfs/file.c b/fs/nfs/file.c index

Re: [Patch] Wait for console to become available, ver 3

On Fri, 17 Apr 2009 14:31:48 -0700 David VomLehn dvoml...@cisco.com wrote: Parallelization to improve boot times has been successful enough that race conditions now exist between the init_post() open of /dev/console and initialization of the console device. When this occurs, opening

Re: [Patch] Wait for console to become available, ver 3

On Mon, 20 Apr 2009, Andrew Morton wrote: If we want b) then how to do it? One possibility: the initcalls have been completed when init_post() is called. How about: if one of those initcalls will be asynchronously registering a console, it should inform the console layer about this. It

Re: [Patch] Wait for console to become available, ver 3

On Mon, 20 Apr 2009 17:51:16 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: On Mon, 20 Apr 2009, Andrew Morton wrote: If we want b) then how to do it? One possibility: the initcalls have been completed when init_post() is called. How about: if one of those initcalls will be

Re: [Patch] Wait for console to become available, ver 3

Personally, I'm in favor of adding a boot parameter. Things could be simplified slightly by treating a negative value (or a missing value) as indicating an infinite timeout; then only one new parameter would be needed instead of two. I'm allergic to the idea of a user interface using

Re: [Patch] Wait for console to become available, ver 3

On Mon, Apr 20, 2009 at 03:14:00PM -0700, Andrew Morton wrote: On Mon, 20 Apr 2009 17:51:16 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: ... What if a subsystem simply doesn't know in advance whether or not it's going to register a console? Or doesn't know when it has finished

Re: [Patch] Wait for console to become available, ver 3

On Mon, 20 Apr 2009 15:35:00 -0700 David VomLehn dvoml...@cisco.com wrote: On Mon, Apr 20, 2009 at 03:14:00PM -0700, Andrew Morton wrote: On Mon, 20 Apr 2009 17:51:16 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: ... What if a subsystem simply doesn't know in advance whether or

Re: [Patch] Wait for console to become available, ver 3

On Mon, Apr 20, 2009 at 03:35:00PM -0700, David VomLehn wrote: With USB, you just can't *ever* get it right. There is no limit on how long a device has to tell you its there. I wish this weren't the case, but our good friends in the USB world tell us that we have been lucky to have had USB

Wait for console to become available, v3.2

Parallelization to improve boot times has been successful enough that race conditions now exist between the init_post() open of /dev/console and initialization of the console device. When this occurs, opening /dev/console fails and any applications inherited from init have no standard in/out/error