public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Steinmetz <ast@domdv.de>
To: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
Cc: herbert@gondor.apana.org.au, davem@davemloft.net,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] crypto: do not open-code be<->cpu
Date: Fri, 22 Apr 2005 12:24:24 +0200	[thread overview]
Message-ID: <4268D0D8.7050104@domdv.de> (raw)
In-Reply-To: <200504221259.03878.vda@port.imtp.ilyichevsk.odessa.ua>

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

      reply	other threads:[~2005-04-22 10:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-22  9:59 [PATCH 1/3] crypto: do not open-code be<->cpu Denis Vlasenko
2005-04-22 10:24 ` Andreas Steinmetz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4268D0D8.7050104@domdv.de \
    --to=ast@domdv.de \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox