Re: [PATCH 01/04] Adding cipher mode context information to crypto_tfm

[Fruhwirth Clemens <clemens@endorphin.org>]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

On Thu, 2005-02-10 at 12:02 -0500, James Morris wrote:
> On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
> 
> > Hm, alright. So I'm going take the internal of kmap_atomic into
> > scatterwalk.c. to test if the page is in highmem, with PageHighMem. If
> > it is, I'm going to kmap_atomic and mark the fixmap as used. If it's
> > not, I do the "mapping" on my own with page_address.
> 
> No, you do not need to do any of this.
> 
> Per previous email, all you need is the existing two kmaps, pass the tweak 
> in as a linear buffer.

Why should I pass the first thing of size X as scatterlist, and the
second thing of size X as linear buffer? 

I could do that. It would be reasonable, because tweaks are more likely
to be generated than transmitted, read or whatever. But what for shall I
narrow the interface? I could also pass a linear mapped buffer as
scatterlist. This doesn't cause any overhead.

And switching to a more specific interface would just delay a solution
of the inherent limitations of kmap's. I guess it will take another half
year until the next guy stumbles across this (totally undocumented!)
problem. Why are you pushing to ignore this problem?

-- 
Fruhwirth Clemens <clemens@endorphin.org>  http://clemens.endorphin.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]