From: "Stephan Müller" <smueller@chronox.de>
To: Benjamin Warnke <4bwarnke@informatik.uni-hamburg.de>
Cc: linux-crypto@vger.kernel.org
Subject: Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram
Date: Tue, 30 Jan 2018 22:26:46 +0100 [thread overview]
Message-ID: <11497171.7hPfTiqTsK@positron.chronox.de> (raw)
In-Reply-To: <C1EF6641-08EB-436C-AD2A-F2581A5BE3FE@informatik.uni-hamburg.de>
Am Dienstag, 30. Januar 2018, 20:49:00 CET schrieb Benjamin Warnke:
Hi Benjamin,
> > In general: I do not think that having larger C functions in header files
> > is a proper coding style.
>
> How should I solve this?
>
> Option 1:
> Move everything in the lib/zbewalgo folder into a single source file.
> This way there is no function defined in a header file.
> I separated the code into different files because the different partial
> compression algorithms are independent from each other.
>
> Option 2:
> Move each header file in its own *.c file, while keeping the
> function-declarations in the header. If the code is scattered in multiple
> source files each of the partial algorithms would show up as an independent
> module. All these modules would load simultaneously with the module
> zbewalgo_compress The module zbewalgo_compress requires an array of all
> partial algorithms. This would spam the 'lsmod' list with unneccessary
> details.
A module may be compiled from multiple C files. So, moving the code into
separate C files and link them into one object / KO should be considered.
>
> > Why are there __attribute__ ((unused)) function parameters, such as in
> > compress_bitshuffle and others?
>
> The zbewalgo algorithm is a container-algorithm for compression functions
> with the ability to concatenate multiple algorithms. To be able to call any
> compression algorithm the same way, I defined 'struct zbewalgo_alg' as the
> interface for all those independent compression algorithms. Some of the
> partial algorithms do not require all parameters. To silence compiler
> warnings (if additional warning flags are enabled) I explicitly add the
> 'unused'-parameter
Linux does not enable the compiler warning about unused parameters.
Ciao
Stephan
next prev parent reply other threads:[~2018-01-30 21:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-30 15:08 Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram Benjamin Warnke
2018-01-30 17:59 ` Stephan Mueller
2018-01-30 19:50 ` Benjamin Warnke
[not found] ` <C1EF6641-08EB-436C-AD2A-F2581A5BE3FE@informatik.uni-hamburg.de>
2018-01-30 21:26 ` Stephan Müller [this message]
2018-01-30 21:37 ` Benjamin Warnke
2018-01-31 6:40 ` Benjamin Warnke
2018-01-31 8:36 ` Benjamin Warnke
2018-01-30 20:24 ` Eric Biggers
2018-01-30 21:27 ` Benjamin Warnke
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=11497171.7hPfTiqTsK@positron.chronox.de \
--to=smueller@chronox.de \
--cc=4bwarnke@informatik.uni-hamburg.de \
--cc=linux-crypto@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox