2005-04-22 10:08:24

by Denis Vlasenko

[permalink] [raw]
Subject: [PATCH 1/3] crypto: do not open-code be<->cpu

Patch replaces numerous be<->cpu and le<->cpu
conversions in crypto. Per lkml comments,
it is done with macros:

block[i] = load_be64(ptr,i);
store_be64(out,i, block[i]);

where i is an index: load_be64 will load i'th
big-endian value pointed by ptr (typically a char*).
Same for store.

This results in smaller and cleaner code.

Patch also adds BYTEn(x) macros for extracting n'th byte from
u32 and u64 memory operand. Currently used experssions like
((K >> 40) & 0xff) are not optimal (gcc will load entire word
and then shift and/or mask it).

Macros can be conditionally defined for different arches
for performance. Ones from this patch are found to be best
for i386.

BYTEn macros are used only by next patches.
--
vda


Attachments:
(No filename) (726.00 B)
1.be_le.patch (46.69 kB)
Download all attachments

2005-04-22 10:25:18

by Andreas Steinmetz

[permalink] [raw]
Subject: Re: [PATCH 1/3] crypto: do not open-code be<->cpu

Denis Vlasenko wrote:
> Patch replaces numerous be<->cpu and le<->cpu
> conversions in crypto. Per lkml comments,
> it is done with macros:
>
> block[i] = load_be64(ptr,i);
> store_be64(out,i, block[i]);
>
> where i is an index: load_be64 will load i'th
> big-endian value pointed by ptr (typically a char*).
> Same for store.
>
> This results in smaller and cleaner code.
>
> Patch also adds BYTEn(x) macros for extracting n'th byte from
> u32 and u64 memory operand. Currently used experssions like
> ((K >> 40) & 0xff) are not optimal (gcc will load entire word
> and then shift and/or mask it).
>
> Macros can be conditionally defined for different arches
> for performance. Ones from this patch are found to be best
> for i386.
>
> BYTEn macros are used only by next patches.

Not good if you use a crypto private header as long as there's arch and
device specific crypto which is left out cold this way.

I'd suggest either some header in include/linux or, in my opinion
better, open a crypto related include directory as include/crypto. The
latter would make sense as there probably will be algorithm specific
headers when the arch and driver specific versions will be harmonized,
thus these headers need to be globally available to crypto sources but
otherwise would pollute the common include directory.
--
Andreas Steinmetz SPAMmers use [email protected]