Paolo Ornati <[email protected]> wrote:
>
> Remove every (hopefully) duplicated word under Documentation/ and do
> other small cleanups.
>
> Examples:
> "and and" --> "and"
> "in in" --> "in"
> ...
When the duplicatation was due to a typo, removing the duplicate is the
not the correct fix. Additionally, there are cases where the text
actually reads better (or no worse) with the duplication in place.
> - matches the field we filled in in the struct
> + matches the field we filled in the struct
Should probably be left as is: "matches the field we (filled in) in
the struct"
> -device. Individual PCI device drivers that have been converted the the current
> +device. Individual PCI device drivers that have been converted the current
First "the" is actually a typo for "to".
> - a directory entry. The directory entry requested carries name name
> + a directory entry. The directory entry requested carries name
> and Venus will search the directory identified by cfs_lookup_in.VFid.
Suspect first "name" should be "the".
> - The CPU to SPU communation mailbox. It is write-only can can be written
> + The CPU to SPU communation mailbox. It is write-only can be written
First "can" should be "and".
> This doesn't seem important in the one button case, but is quite important
> -for for example mouse movement, where you don't want the X and Y values
> +for example mouse movement, where you don't want the X and Y values
> to be interpreted separately, because that'd result in a different movement.
Probably should be rephrased in general. Author probably intended it to
be parsed as "...but is quite important for, for example, mouse
movement...".
> -a trailing = on the name of any parameter states that that parameter will
> +a trailing = on the name of any parameter states that parameter will
Again, "states that (that parameter)" while not great English is
probably exactly what the author intended.
> Life isn't quite as simple as it may appear above, however: for while the
> -caches are expected to be coherent, there's no guarantee that that coherency
> +caches are expected to be coherent, there's no guarantee that coherency
> will be ordered. This means that whilst changes made on one CPU will
And again: "...no guarantee that (that coherency) will be...".
...possibly more; this is as far as I got.
--Adam
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
