lkml.org 
[lkml]   [2005]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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 robotrap@domdv.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-22 12:29    [W:0.048 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site