From: Paolo Ornati <ornati@gmail.com>
To: Alistair John Strachan <s0348365@sms.ed.ac.uk>
Cc: jensmh@gmx.de,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
trivial@kernel.org, Paolo Ornati <ornati@fastwebnet.it>
Subject: Re: [PATCH] Documentation: remove duplicate cleanups
Date: Thu, 29 Jun 2006 15:05:45 +0200 [thread overview]
Message-ID: <20060629150545.167c0abb@localhost> (raw)
In-Reply-To: <200606291339.11733.s0348365@sms.ed.ac.uk>
On Thu, 29 Jun 2006 13:39:11 +0100
Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> On Thursday 29 June 2006 13:12, Paolo Ornati wrote:
> > On Thu, 29 Jun 2006 14:02:18 +0200
> >
> > jensmh@gmx.de wrote:
> > > > diff --git a/Documentation/block/as-iosched.txt
> > > > b/Documentation/block/as-iosched.txt index 6f47332..ed24cdd 100644
> > > > --- a/Documentation/block/as-iosched.txt
> > > > +++ b/Documentation/block/as-iosched.txt
> > > > @@ -111,7 +111,7 @@ or if the next request in the queue is "
> > > > just completed request, it is dispatched immediately. Otherwise,
> > > > statistics (average think time, average seek distance) on the process
> > > > that submitted the just completed request are examined. If it seems
> > > > -likely that that process will submit another request soon, and that
> > >
> > > old version is correct, I think.
> >
> > me too (I've exagerated a bit in killing duplicates ;)
>
> "that the process"
Are you sure?
To me it makes more sense the old one when read in the context.
>
> > > > +likely that process will submit another request soon, and that
> > > > request is likely to be near the just completed request, then the IO
> > > > scheduler will stop dispatching more read requests for up time
> > > > (antic_expire) milliseconds, hoping that process will submit a new
> > > > request near the one
> > > >
> > > >
> > > > diff --git a/Documentation/exception.txt b/Documentation/exception.txt
> > > > index 3cb39ad..75aaa6e 100644
> > > > --- a/Documentation/exception.txt
> > > > +++ b/Documentation/exception.txt
> > > > @@ -10,7 +10,7 @@ int verify_area(int type, const void * a
> > > > function (which has since been replaced by access_ok()).
> > > >
> > > > This function verified that the memory area starting at address
> > > > -addr and of size size was accessible for the operation specified
> > >
> > > maybe old version is correct.
> >
> > yes
>
> Agreed, but no harm in single quotes around 'addr' and 'size'.
I agree.
>
> > > > +addr and of size was accessible for the operation specified
> > > > in type (read or write). To do this, verify_read had to look up the
> > > > virtual memory area (vma) that contained the address addr. In the
> > > > normal case (correctly working program), this test was successful.
> > > > diff --git a/Documentation/fb/fbcon.txt b/Documentation/fb/fbcon.txt
> > > > index f373df1..4a9739a 100644
> > > > --- a/Documentation/fb/fbcon.txt
> > > > +++ b/Documentation/fb/fbcon.txt
> > > > @@ -150,7 +150,7 @@ C. Boot options
> > > >
> > > > C. Attaching, Detaching and Unloading
> > > >
> > > > -Before going on on how to attach, detach and unload the framebuffer
> > > > console, an
> > >
> > > not sure here, I'm not a native english speaker.
> >
> > yes, the old one looks correct
>
> I disagree. The cleanup's either an improvement, or the sentence should be
> rewritten, "Before continuing with how to attach, detect and unload the
> framebuffer.."
>
> I think if you're going to improve the quality of documentation, there's no
> harm to make minor grammatical improvements. Duplicate words are almost
> always a bad thing, and they really disrupt reading flow.
Maybe, but I'll probably make more danger than anything.
For now I just want to eliminate the wrong duplicates and keep the
correct ones.
--
Paolo Ornati
Linux 2.6.17.1 on x86_64
next prev parent reply other threads:[~2006-06-29 13:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-29 11:40 [PATCH] Documentation: remove duplicate cleanups Paolo Ornati
2006-06-29 11:43 ` Paolo Ornati
2006-06-29 11:51 ` jensmh
2006-06-29 11:58 ` Paolo Ornati
2006-06-29 12:35 ` Alistair John Strachan
2006-06-29 12:02 ` jensmh
2006-06-29 12:12 ` Paolo Ornati
2006-06-29 12:39 ` Alistair John Strachan
2006-06-29 13:05 ` Paolo Ornati [this message]
2006-06-29 13:35 ` Alistair John Strachan
2006-06-29 14:06 ` Paolo Ornati
2006-06-29 13:11 ` Paolo Ornati
2006-06-29 13:48 ` Valdis.Kletnieks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060629150545.167c0abb@localhost \
--to=ornati@gmail.com \
--cc=jensmh@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ornati@fastwebnet.it \
--cc=s0348365@sms.ed.ac.uk \
--cc=trivial@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.