All of lore.kernel.org
 help / color / mirror / Atom feed
From: LABBE Corentin <clabbe@baylibre.com>
To: herbert@gondor.apana.org.au
Cc: davem@davemloft.net, nhorman@tuxdriver.com,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	smueller@chronox.de
Subject: Re: [PATCH 1/2] crypto: Implement a generic crypto statistics
Date: Thu, 18 Jan 2018 09:58:13 +0100	[thread overview]
Message-ID: <20180118085813.GA1988@Red> (raw)
In-Reply-To: <16302559.hxlYq3rOsN@tauon.chronox.de>

On Fri, Jan 12, 2018 at 10:11:18AM +0100, Stephan Mueller wrote:
> Am Freitag, 12. Januar 2018, 10:07:30 CET schrieb LABBE Corentin:
> 
> > > > +	__u64 stat_hash_tlen;
> > > > 
> > > >  };
> > > 
> > > What I am slightly unsure here is: how should user space detect whether
> > > these additional parameters are part of the NETLINK_USER API or not? I
> > > use that interface in my libkcapi whose binary may be used on multiple
> > > different kernel versions. How should that library operate if one kernel
> > > has these parameters and another does not?
> > 
> > Userspace could check for kernel version and know if stat are present or
> > not. Another way is to add a new netlink request.
> 
> Well, I am not sure that checking the kernel version is good enough. Distros 
> and other vendors may backport this patch. This means that for some older 
> kernel versions this interface is present.
> 
> Hence I would rather opt for a separate stat message where the user spacee 
> caller receives an error on kernels that does not support it.
> 
Herbert,
I have two way of adding a new netlink request
- keep the current patch and simply add a new CRYPTO_MSG_GETSTAT which use the same function than CRYPTO_MSG_GETALG
	=> minimal changes, in fact CRYPTO_MSG_GETSTAT and CRYPTO_MSG_GETALG would be the same, but it is easy for userspace to test presence of stat.
- Create a new CRYPTO_MSG_GETSTAT which imply lot of code and add a new crypto_user_stat.c
	=> this imply also to change makefile (rename crypto_user.c to crypto_user_base.c) since crypto_user.ko is made of two files.

Which one do you prefer ?

Regards

  reply	other threads:[~2018-01-18  8:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-11 19:56 [PATCH 0/2] crypto: Implement generic crypto statistics Corentin Labbe
2018-01-11 19:56 ` [PATCH 1/2] crypto: Implement a " Corentin Labbe
2018-01-12  6:49   ` Stephan Mueller
2018-01-12  9:07     ` LABBE Corentin
2018-01-12  9:11       ` Stephan Mueller
2018-01-18  8:58         ` LABBE Corentin [this message]
2018-01-26 15:43           ` Herbert Xu
2018-01-31  8:33             ` Steffen Klassert
2018-01-11 19:56 ` [PATCH 2/2] crypto: tools: Add cryptostat userspace Corentin Labbe

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=20180118085813.GA1988@Red \
    --to=clabbe@baylibre.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=smueller@chronox.de \
    /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.