[PATCH -next] lib: zstd: Make symbol 'HUF_compressWeights_wksp' static

[PATCH -next] lib: zstd: Make symbol 'HUF_compressWeights_wksp' static

[Zhao Xuehui]

The symbol 'HUF_compressWeights_wksp' is not used outside of
huf_compress.c, so this commit marks it static.

Signed-off-by: Zhao Xuehui <zhaoxuehui1@huawei.com>
---
 lib/zstd/huf_compress.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/zstd/huf_compress.c b/lib/zstd/huf_compress.c
index fd32838c185f..1e5e001c3d41 100644
--- a/lib/zstd/huf_compress.c
+++ b/lib/zstd/huf_compress.c
@@ -79,7 +79,8 @@ unsigned HUF_optimalTableLog(unsigned maxTableLog, size_t srcSize, unsigned maxS
  * Note : all elements within weightTable are supposed to be <= HUF_TABLELOG_MAX.
  */
 #define MAX_FSE_TABLELOG_FOR_HUFF_HEADER 6
-size_t HUF_compressWeights_wksp(void *dst, size_t dstSize, const void *weightTable, size_t wtSize, void *workspace, size_t workspaceSize)
+static size_t HUF_compressWeights_wksp(void *dst, size_t dstSize, const void *weightTable,
+				       size_t wtSize, void *workspace, size_t workspaceSize)
 {
 	BYTE *const ostart = (BYTE *)dst;
 	BYTE *op = ostart;

Re: [PATCH -next] lib: zstd: Make symbol 'HUF_compressWeights_wksp' static

[Nick Desaulniers]

On Thu, Apr 8, 2021 at 5:55 AM Zhao Xuehui <zhaoxuehui1@huawei.com> wrote:
>
> The symbol 'HUF_compressWeights_wksp' is not used outside of
> huf_compress.c, so this commit marks it static.

Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

Quite a few other functions are declared in a header, but I don't see
any existing callers in tree.  I wonder if the maintainer could
consider cleaning these up so that we don't retain them in binaries
without dead code elimination enabled, or if there's a need to keep
this code in line with an external upstream codebase?

>
> Signed-off-by: Zhao Xuehui <zhaoxuehui1@huawei.com>
> ---
>  lib/zstd/huf_compress.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/zstd/huf_compress.c b/lib/zstd/huf_compress.c
> index fd32838c185f..1e5e001c3d41 100644
> --- a/lib/zstd/huf_compress.c
> +++ b/lib/zstd/huf_compress.c
> @@ -79,7 +79,8 @@ unsigned HUF_optimalTableLog(unsigned maxTableLog, size_t srcSize, unsigned maxS
>   * Note : all elements within weightTable are supposed to be <= HUF_TABLELOG_MAX.
>   */
>  #define MAX_FSE_TABLELOG_FOR_HUFF_HEADER 6
> -size_t HUF_compressWeights_wksp(void *dst, size_t dstSize, const void *weightTable, size_t wtSize, void *workspace, size_t workspaceSize)
> +static size_t HUF_compressWeights_wksp(void *dst, size_t dstSize, const void *weightTable,
> +                                      size_t wtSize, void *workspace, size_t workspaceSize)
>  {
>         BYTE *const ostart = (BYTE *)dst;
>         BYTE *op = ostart;
>


-- 
Thanks,
~Nick Desaulniers

Re: [PATCH -next] lib: zstd: Make symbol 'HUF_compressWeights_wksp' static

[Miguel Ojeda]

On Fri, Apr 9, 2021 at 2:20 AM Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> Quite a few other functions are declared in a header, but I don't see
> any existing callers in tree.  I wonder if the maintainer could
> consider cleaning these up so that we don't retain them in binaries
> without dead code elimination enabled, or if there's a need to keep
> this code in line with an external upstream codebase?

Yeah, the equivalent cleanup was done upstream by Nick in 2018 [1],
but there has been no major update to lib/zstd since 2017.

Thus a cleanup would actually make it closer to upstream, which is the
best case scenario :)

    Reviewed-by: Miguel Ojeda <ojeda@kernel.org>

[1] https://github.com/facebook/zstd/commit/f2d6db45cd28457fa08467416e8535985f062859

Cheers,
Miguel

Re: [PATCH -next] lib: zstd: Make symbol 'HUF_compressWeights_wksp' static

[Nick Terrell]

> On Apr 8, 2021, at 8:09 PM, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> 
> On Fri, Apr 9, 2021 at 2:20 AM Nick Desaulniers <ndesaulniers@google.com> wrote:
>> 
>> Quite a few other functions are declared in a header, but I don't see
>> any existing callers in tree.  I wonder if the maintainer could
>> consider cleaning these up so that we don't retain them in binaries
>> without dead code elimination enabled, or if there's a need to keep
>> this code in line with an external upstream codebase?
> 
> Yeah, the equivalent cleanup was done upstream by Nick in 2018 [1],
> but there has been no major update to lib/zstd since 2017.
> 
> Thus a cleanup would actually make it closer to upstream, which is the
> best case scenario :)
> 
>    Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
> 
> [1] https://github.com/facebook/zstd/commit/f2d6db45cd28457fa08467416e8535985f062859

This looks good to me as well. I have a patchset up to use upstream zstd directly in the kernel [0].
That will allow us to keep zstd up to date. And after that lands, I hope to set up a zstd linux tree
to make merging patches into lib/zstd easier, since over the years quite a few have been ignored.

[0] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2532407.html

Best,
Nick Terrell

> Cheers,
> Miguel