Am Donnerstag, 13. Oktober 2016, 15:08:41 CEST schrieb Gary R Hook:
Hi Gary,
> On 10/13/2016 01:25 PM, Stephan Mueller wrote:
> > Am Donnerstag, 13. Oktober 2016, 09:53:09 CEST schrieb Gary R Hook:
> >
> > Hi Gary,
> >
> >> Wire up the v3 CCP as a cipher provider.
> >>
> >> Signed-off-by: Gary R Hook <gary.h...@amd.com>
> >> ---
> >>
> >> ...snip...
> >>
> >> +}
> >> +
> >> +static void ccp_free_mpi_key(struct ccp_rsa_key *key)
> >> +{
> >> + mpi_free(key->d);
> >> + key->d = NULL;
> >> + mpi_free(key->e);
> >> + key->e = NULL;
> >> + mpi_free(key->n);
> >> + key->n = NULL;
> >> +}
> >
> > Could you please see whether that function can be turned into a common
> > function call? crypto/rsa.c implements the same code in rsa_free_mpi_key.
>
> I am happy to do so, but was unsure of protocol. rsa.c is in a module, which
> makes my module depend upon another. I do not want to do that. And moving
> this function elsewhere makes no sense.
>
> I would go with an inline function, but there's no obvious place for it.
> The RSA software implementation uses the MPI library, but there's no
> requirement to do so (witness the qat driver). Thus, an inline function
> can't
> be put in internal/rsa.h without moving the rsa_mpi_key definition and
> referencing mpi.h.
>
> I think that RSA+MPI things, such as rsa_mpi_key and this function, could go
> into internal/rsa.h, but it would be necessary to #include mpi.h.
>
> Or: create a new include file that contains these (and any other) RSA/MPI
> amalgams.
>
> Which would you prefer?
I would guess it should go to include/crypto/internal/rsa.h as an inline
considering that the "internal" header files are for crypto provider code.
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
