Linux cryptographic layer development
 help / color / mirror / Atom feed
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

  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