All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH trivial] docs: fix core_pipe_limit info
@ 2009-10-05  2:23 Randy Dunlap
  2009-10-05 22:03 ` Jiri Kosina
  0 siblings, 1 reply; 3+ messages in thread
From: Randy Dunlap @ 2009-10-05  2:23 UTC (permalink / raw)
  To: LKML; +Cc: trivial, nhorman

From: Randy Dunlap <randy.dunlap@oracle.com>

Fix typos in core_pipe_limit info.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
 Documentation/sysctl/kernel.txt |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- linux-next-20090930.orig/Documentation/sysctl/kernel.txt
+++ linux-next-20090930/Documentation/sysctl/kernel.txt
@@ -139,9 +139,9 @@ core_pattern is used to specify a core d
 core_pipe_limit:
 
 This sysctl is only applicable when core_pattern is configured to pipe core
-files to user space helper a (when the first character of core_pattern is a '|',
+files to a user space helper (when the first character of core_pattern is a '|',
 see above).  When collecting cores via a pipe to an application, it is
-occasionally usefull for the collecting application to gather data about the
+occasionally useful for the collecting application to gather data about the
 crashing process from its /proc/pid directory.  In order to do this safely, the
 kernel must wait for the collecting process to exit, so as not to remove the
 crashing processes proc files prematurely.  This in turn creates the possibility
@@ -152,7 +152,7 @@ applications in parallel.  If this value
 processes above that value are noted via the kernel log and their cores are
 skipped.  0 is a special value, indicating that unlimited processes may be
 captured in parallel, but that no waiting will take place (i.e. the collecting
-process is not guaranteed access to /proc/<crahing pid>/).  This value defaults
+process is not guaranteed access to /proc/<crashing pid>/).  This value defaults
 to 0.
 
 ==============================================================

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH trivial] docs: fix core_pipe_limit info
  2009-10-05  2:23 [PATCH trivial] docs: fix core_pipe_limit info Randy Dunlap
@ 2009-10-05 22:03 ` Jiri Kosina
  2009-10-05 23:47   ` Neil Horman
  0 siblings, 1 reply; 3+ messages in thread
From: Jiri Kosina @ 2009-10-05 22:03 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: LKML, nhorman

On Sun, 4 Oct 2009, Randy Dunlap wrote:

> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> Fix typos in core_pipe_limit info.
> 
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> ---
>  Documentation/sysctl/kernel.txt |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> --- linux-next-20090930.orig/Documentation/sysctl/kernel.txt
> +++ linux-next-20090930/Documentation/sysctl/kernel.txt
> @@ -139,9 +139,9 @@ core_pattern is used to specify a core d
>  core_pipe_limit:
>  
>  This sysctl is only applicable when core_pattern is configured to pipe core
> -files to user space helper a (when the first character of core_pattern is a '|',
> +files to a user space helper (when the first character of core_pattern is a '|',
>  see above).  When collecting cores via a pipe to an application, it is
> -occasionally usefull for the collecting application to gather data about the
> +occasionally useful for the collecting application to gather data about the
>  crashing process from its /proc/pid directory.  In order to do this safely, the
>  kernel must wait for the collecting process to exit, so as not to remove the
>  crashing processes proc files prematurely.  This in turn creates the possibility
> @@ -152,7 +152,7 @@ applications in parallel.  If this value
>  processes above that value are noted via the kernel log and their cores are
>  skipped.  0 is a special value, indicating that unlimited processes may be
>  captured in parallel, but that no waiting will take place (i.e. the collecting
> -process is not guaranteed access to /proc/<crahing pid>/).  This value defaults
> +process is not guaranteed access to /proc/<crashing pid>/).  This value defaults
>  to 0.

Applied to trivial queue, thanks Randy.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH trivial] docs: fix core_pipe_limit info
  2009-10-05 22:03 ` Jiri Kosina
@ 2009-10-05 23:47   ` Neil Horman
  0 siblings, 0 replies; 3+ messages in thread
From: Neil Horman @ 2009-10-05 23:47 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: Randy Dunlap, LKML

On Tue, Oct 06, 2009 at 12:03:40AM +0200, Jiri Kosina wrote:
> On Sun, 4 Oct 2009, Randy Dunlap wrote:
> 
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> > 
> > Fix typos in core_pipe_limit info.
> > 
> > Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> > Cc: Neil Horman <nhorman@tuxdriver.com>
> > ---
> >  Documentation/sysctl/kernel.txt |    6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > --- linux-next-20090930.orig/Documentation/sysctl/kernel.txt
> > +++ linux-next-20090930/Documentation/sysctl/kernel.txt
> > @@ -139,9 +139,9 @@ core_pattern is used to specify a core d
> >  core_pipe_limit:
> >  
> >  This sysctl is only applicable when core_pattern is configured to pipe core
> > -files to user space helper a (when the first character of core_pattern is a '|',
> > +files to a user space helper (when the first character of core_pattern is a '|',
> >  see above).  When collecting cores via a pipe to an application, it is
> > -occasionally usefull for the collecting application to gather data about the
> > +occasionally useful for the collecting application to gather data about the
> >  crashing process from its /proc/pid directory.  In order to do this safely, the
> >  kernel must wait for the collecting process to exit, so as not to remove the
> >  crashing processes proc files prematurely.  This in turn creates the possibility
> > @@ -152,7 +152,7 @@ applications in parallel.  If this value
> >  processes above that value are noted via the kernel log and their cores are
> >  skipped.  0 is a special value, indicating that unlimited processes may be
> >  captured in parallel, but that no waiting will take place (i.e. the collecting
> > -process is not guaranteed access to /proc/<crahing pid>/).  This value defaults
> > +process is not guaranteed access to /proc/<crashing pid>/).  This value defaults
> >  to 0.
> 
> Applied to trivial queue, thanks Randy.
> 
Thank you Randy, Jiri.
Neil

> -- 
> Jiri Kosina
> SUSE Labs, Novell Inc.
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-10-05 23:48 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-05  2:23 [PATCH trivial] docs: fix core_pipe_limit info Randy Dunlap
2009-10-05 22:03 ` Jiri Kosina
2009-10-05 23:47   ` Neil Horman

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.