[ewg] RHEL5 backports and crypto functions

[Brian J. Murrell]

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?

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

Thanx,
b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20090501/93d585ed/attachment.sig>