From: Gao Xiang <xiang@kernel.org> To: linux-erofs@lists.ozlabs.org, LKML <linux-kernel@vger.kernel.org> Cc: Lasse Collin <lasse.collin@tukaani.org>, Chao Yu <chao@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Greg KH <gregkh@linuxfoundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, Gao Xiang <hsiangkao@linux.alibaba.com> Subject: [PATCH 5/7] lib/xz, lib/decompress_unxz.c: Fix spelling in comments Date: Mon, 11 Oct 2021 05:31:43 +0800 [thread overview] Message-ID: <20211010213145.17462-6-xiang@kernel.org> (raw) In-Reply-To: <20211010213145.17462-1-xiang@kernel.org> From: Lasse Collin <lasse.collin@tukaani.org> uncompressible -> incompressible non-splitted -> non-split Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> --- lib/decompress_unxz.c | 10 +++++----- lib/xz/xz_dec_lzma2.c | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/lib/decompress_unxz.c b/lib/decompress_unxz.c index f7a3dc13316a..9f4262ee33a5 100644 --- a/lib/decompress_unxz.c +++ b/lib/decompress_unxz.c @@ -20,8 +20,8 @@ * * The worst case for in-place decompression is that the beginning of * the file is compressed extremely well, and the rest of the file is - * uncompressible. Thus, we must look for worst-case expansion when the - * compressor is encoding uncompressible data. + * incompressible. Thus, we must look for worst-case expansion when the + * compressor is encoding incompressible data. * * The structure of the .xz file in case of a compressed kernel is as follows. * Sizes (as bytes) of the fields are in parenthesis. @@ -58,7 +58,7 @@ * uncompressed size of the payload is in practice never less than the * payload size itself. The LZMA2 format would allow uncompressed size * to be less than the payload size, but no sane compressor creates such - * files. LZMA2 supports storing uncompressible data in uncompressed form, + * files. LZMA2 supports storing incompressible data in uncompressed form, * so there's never a need to create payloads whose uncompressed size is * smaller than the compressed size. * @@ -167,8 +167,8 @@ * memeq and memzero are not used much and any remotely sane implementation * is fast enough. memcpy/memmove speed matters in multi-call mode, but * the kernel image is decompressed in single-call mode, in which only - * memmove speed can matter and only if there is a lot of uncompressible data - * (LZMA2 stores uncompressible chunks in uncompressed form). Thus, the + * memmove speed can matter and only if there is a lot of incompressible data + * (LZMA2 stores incompressible chunks in uncompressed form). Thus, the * functions below should just be kept small; it's probably not worth * optimizing for speed. */ diff --git a/lib/xz/xz_dec_lzma2.c b/lib/xz/xz_dec_lzma2.c index 46b186d7eb45..27ce34520e78 100644 --- a/lib/xz/xz_dec_lzma2.c +++ b/lib/xz/xz_dec_lzma2.c @@ -520,7 +520,7 @@ static __always_inline void rc_normalize(struct rc_dec *rc) * functions so that the compiler is supposed to be able to more easily avoid * an extra branch. In this particular version of the LZMA decoder, this * doesn't seem to be a good idea (tested with GCC 3.3.6, 3.4.6, and 4.3.3 - * on x86). Using a non-splitted version results in nicer looking code too. + * on x86). Using a non-split version results in nicer looking code too. * * NOTE: This must return an int. Do not make it return a bool or the speed * of the code generated by GCC 3.x decreases 10-15 %. (GCC 4.3 doesn't care, -- 2.20.1
WARNING: multiple messages have this Message-ID (diff)
From: Gao Xiang <xiang@kernel.org> To: linux-erofs@lists.ozlabs.org, LKML <linux-kernel@vger.kernel.org> Cc: Lasse Collin <lasse.collin@tukaani.org>, Greg KH <gregkh@linuxfoundation.org>, Gao Xiang <hsiangkao@linux.alibaba.com>, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org> Subject: [PATCH 5/7] lib/xz, lib/decompress_unxz.c: Fix spelling in comments Date: Mon, 11 Oct 2021 05:31:43 +0800 [thread overview] Message-ID: <20211010213145.17462-6-xiang@kernel.org> (raw) In-Reply-To: <20211010213145.17462-1-xiang@kernel.org> From: Lasse Collin <lasse.collin@tukaani.org> uncompressible -> incompressible non-splitted -> non-split Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> --- lib/decompress_unxz.c | 10 +++++----- lib/xz/xz_dec_lzma2.c | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/lib/decompress_unxz.c b/lib/decompress_unxz.c index f7a3dc13316a..9f4262ee33a5 100644 --- a/lib/decompress_unxz.c +++ b/lib/decompress_unxz.c @@ -20,8 +20,8 @@ * * The worst case for in-place decompression is that the beginning of * the file is compressed extremely well, and the rest of the file is - * uncompressible. Thus, we must look for worst-case expansion when the - * compressor is encoding uncompressible data. + * incompressible. Thus, we must look for worst-case expansion when the + * compressor is encoding incompressible data. * * The structure of the .xz file in case of a compressed kernel is as follows. * Sizes (as bytes) of the fields are in parenthesis. @@ -58,7 +58,7 @@ * uncompressed size of the payload is in practice never less than the * payload size itself. The LZMA2 format would allow uncompressed size * to be less than the payload size, but no sane compressor creates such - * files. LZMA2 supports storing uncompressible data in uncompressed form, + * files. LZMA2 supports storing incompressible data in uncompressed form, * so there's never a need to create payloads whose uncompressed size is * smaller than the compressed size. * @@ -167,8 +167,8 @@ * memeq and memzero are not used much and any remotely sane implementation * is fast enough. memcpy/memmove speed matters in multi-call mode, but * the kernel image is decompressed in single-call mode, in which only - * memmove speed can matter and only if there is a lot of uncompressible data - * (LZMA2 stores uncompressible chunks in uncompressed form). Thus, the + * memmove speed can matter and only if there is a lot of incompressible data + * (LZMA2 stores incompressible chunks in uncompressed form). Thus, the * functions below should just be kept small; it's probably not worth * optimizing for speed. */ diff --git a/lib/xz/xz_dec_lzma2.c b/lib/xz/xz_dec_lzma2.c index 46b186d7eb45..27ce34520e78 100644 --- a/lib/xz/xz_dec_lzma2.c +++ b/lib/xz/xz_dec_lzma2.c @@ -520,7 +520,7 @@ static __always_inline void rc_normalize(struct rc_dec *rc) * functions so that the compiler is supposed to be able to more easily avoid * an extra branch. In this particular version of the LZMA decoder, this * doesn't seem to be a good idea (tested with GCC 3.3.6, 3.4.6, and 4.3.3 - * on x86). Using a non-splitted version results in nicer looking code too. + * on x86). Using a non-split version results in nicer looking code too. * * NOTE: This must return an int. Do not make it return a bool or the speed * of the code generated by GCC 3.x decreases 10-15 %. (GCC 4.3 doesn't care, -- 2.20.1
next prev parent reply other threads:[~2021-10-10 21:32 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-10 21:31 [PATCH 0/7] erofs: add LZMA compression support Gao Xiang 2021-10-10 21:31 ` Gao Xiang 2021-10-10 21:31 ` [PATCH 1/7] lib/xz: Avoid overlapping memcpy() with invalid input with in-place decompression Gao Xiang 2021-10-10 21:31 ` Gao Xiang 2021-10-10 21:31 ` [PATCH 2/7] lib/xz: Validate the value before assigning it to an enum variable Gao Xiang 2021-10-10 21:31 ` Gao Xiang 2021-10-10 21:31 ` [PATCH 3/7] lib/xz: Move s->lzma.len = 0 initialization to lzma_reset() Gao Xiang 2021-10-10 21:31 ` Gao Xiang 2021-10-10 21:31 ` [PATCH 4/7] lib/xz: Add MicroLZMA decoder Gao Xiang 2021-10-10 21:31 ` Gao Xiang 2021-10-10 21:31 ` Gao Xiang [this message] 2021-10-10 21:31 ` [PATCH 5/7] lib/xz, lib/decompress_unxz.c: Fix spelling in comments Gao Xiang 2021-10-10 21:31 ` [PATCH 6/7] erofs: rename some generic methods in decompressor Gao Xiang 2021-10-10 21:31 ` Gao Xiang 2021-10-19 13:03 ` Chao Yu 2021-10-19 13:03 ` Chao Yu 2021-10-10 21:31 ` [PATCH 7/7] erofs: lzma compression support Gao Xiang 2021-10-10 21:31 ` Gao Xiang 2021-10-19 13:04 ` Chao Yu 2021-10-19 13:04 ` Chao Yu 2021-10-14 1:45 ` [PATCH 0/7] erofs: add LZMA " Gao Xiang 2021-10-14 1:45 ` Gao Xiang
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=20211010213145.17462-6-xiang@kernel.org \ --to=xiang@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=chao@kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=hsiangkao@linux.alibaba.com \ --cc=lasse.collin@tukaani.org \ --cc=linux-erofs@lists.ozlabs.org \ --cc=linux-kernel@vger.kernel.org \ --cc=torvalds@linux-foundation.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: linkBe 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.