From: Tyler Hicks <tyhicks@canonical.com>
To: Chris J Arges <chris.j.arges@canonical.com>
Cc: ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ecryptfs: fix spelling mistakes
Date: Mon, 20 Jun 2016 10:11:08 -0500 [thread overview]
Message-ID: <5768078C.4080701@canonical.com> (raw)
In-Reply-To: <1465504293-23323-1-git-send-email-chris.j.arges@canonical.com>
[-- Attachment #1.1: Type: text/plain, Size: 3355 bytes --]
On 06/09/2016 03:31 PM, Chris J Arges wrote:
> Noticed some minor spelling errors when looking through the code.
>
> Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Hey Chris - thanks for these fixups. The first two hunks
(respresentation -> representation) were already fixed by an older patch
that is pending in the eCryptfs next branch. I dropped those hunks,
added my S-o-b, and pushed this patch to the eCryptfs next branch.
Tyler
> ---
> fs/ecryptfs/crypto.c | 8 ++++----
> fs/ecryptfs/file.c | 4 ++--
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
> index 0d8eb34..e5e29f8 100644
> --- a/fs/ecryptfs/crypto.c
> +++ b/fs/ecryptfs/crypto.c
> @@ -45,7 +45,7 @@
> * ecryptfs_to_hex
> * @dst: Buffer to take hex character representation of contents of
> * src; must be at least of size (src_size * 2)
> - * @src: Buffer to be converted to a hex string respresentation
> + * @src: Buffer to be converted to a hex string representation
> * @src_size: number of bytes to convert
> */
> void ecryptfs_to_hex(char *dst, char *src, size_t src_size)
> @@ -60,7 +60,7 @@ void ecryptfs_to_hex(char *dst, char *src, size_t src_size)
> * ecryptfs_from_hex
> * @dst: Buffer to take the bytes from src hex; must be at least of
> * size (src_size / 2)
> - * @src: Buffer to be converted from a hex string respresentation to raw value
> + * @src: Buffer to be converted from a hex string representation to raw value
> * @dst_size: size of dst buffer, or number of hex characters pairs to convert
> */
> void ecryptfs_from_hex(char *dst, char *src, int dst_size)
> @@ -953,7 +953,7 @@ struct ecryptfs_cipher_code_str_map_elem {
> };
>
> /* Add support for additional ciphers by adding elements here. The
> - * cipher_code is whatever OpenPGP applicatoins use to identify the
> + * cipher_code is whatever OpenPGP applications use to identify the
> * ciphers. List in order of probability. */
> static struct ecryptfs_cipher_code_str_map_elem
> ecryptfs_cipher_code_str_map[] = {
> @@ -1410,7 +1410,7 @@ int ecryptfs_read_and_validate_xattr_region(struct dentry *dentry,
> *
> * Common entry point for reading file metadata. From here, we could
> * retrieve the header information from the header region of the file,
> - * the xattr region of the file, or some other repostory that is
> + * the xattr region of the file, or some other repository that is
> * stored separately from the file itself. The current implementation
> * supports retrieving the metadata information from the file contents
> * and from the xattr region.
> diff --git a/fs/ecryptfs/file.c b/fs/ecryptfs/file.c
> index 7000b96..53d0141 100644
> --- a/fs/ecryptfs/file.c
> +++ b/fs/ecryptfs/file.c
> @@ -171,7 +171,7 @@ out:
>
> /**
> * ecryptfs_open
> - * @inode: inode speciying file to open
> + * @inode: inode specifying file to open
> * @file: Structure to return filled in
> *
> * Opens the file specified by inode.
> @@ -240,7 +240,7 @@ out:
>
> /**
> * ecryptfs_dir_open
> - * @inode: inode speciying file to open
> + * @inode: inode specifying file to open
> * @file: Structure to return filled in
> *
> * Opens the file specified by inode.
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
prev parent reply other threads:[~2016-06-20 15:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-09 20:31 [PATCH] ecryptfs: fix spelling mistakes Chris J Arges
2016-06-20 15:11 ` Tyler Hicks [this message]
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=5768078C.4080701@canonical.com \
--to=tyhicks@canonical.com \
--cc=chris.j.arges@canonical.com \
--cc=ecryptfs@vger.kernel.org \
--cc=linux-kernel@vger.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.