[ewg] RHEL5 backports and crypto functions

[Jon Mason]

On Fri, May 01, 2009 at 12:05:27PM -0400, Brian J. Murrell wrote:
> Hi,
> 
> I've just filed bug 1620 against 1.4.1.  It was suggested I also post a
> message here in case there is any discussion needed.
> 
> I was looking at another aspect of the RHEL5 backports and found another
> area that looks like a problem.  I am hoping we can act quickly to try
> to resolve this before 1.4.1 GA as this is another problem that will
> prevent us from being able to build our driver with OFED 1.4.1.
> 
> What seems to be at issue is the backport definition of struct hash_desc
> in
> 
> ofa_kernel/kernel_addons/backport/2.6.18-EL5.3/include/linux/crypto.h 
> 
> which is:
> 
> struct hash_desc
> {
> 	struct crypto_tfm *tfm;
> 	u32 flags;
> };
> 
> I'm far from even slightly knowledgeable on the Linux kernel's crypto
> facilities but I'm just trying to see how this meets up (or fails to)
> with our code's use of struct hash_desc.
> 
> For reference I went to the vanilla kernel's implementation of this
> struct and it seems to have been introduced in 2.6.19 as:
> 
> struct hash_desc {
>         struct crypto_hash *tfm;
>         u32 flags;
> };
> 
> and has not changed all the way up to and including 2.6.29.
> 
> The problem is that we use struct hash_desc in our code and we expect it
> to have the same definition as the kernel, specifically, we expect tfm
> to be of type "crypto_hash *".
> 
> I'm wondering why the OFED backports have a different definition than
> the kernel has?

It's the same definition as the distro kernel has.  So the struct has
changed since 2.6.18.  However, it should not be necessary to ship these
files, and they are simply redefining structs and funcs found in
ncrypto.h (in the distro kernel).

I am in the process of trying to rip those out and use the existing
definitions in ncrypto.h, but it is a bit of a tangled mess.  I assume
that not having it defined in the backport header files would work
around the issue you are experiencing, correct?

Thanks,
Jon

> 
> As we are getting close to a release, I am hoping we can resolve this
> quickly.
> 
> Thanx,
> b.
> 



> _______________________________________________
> ewg mailing list
> ewg at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg