Re: [PATCH] crypto: serpent - add x86_64/avx assemblerimplementation

[Jussi Kivilinna]

Quoting Johannes Goetzfried  
<Johannes.Goetzfried@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>:

> Hello,
>
> > Should be serpent_sse2_glue.c?
>
> Yeah, same error as in the other patch :-)
>
> > >+}, {
> > >+	.cra_name		= "ecb(serpent)",
> > >+	.cra_driver_name	= "ecb-serpent-avx",
> > >+	.cra_priority		= 400,
> >
> > serpent_sse2_glue.c has priority 400 too, so you should increase
> > priority here to 500.
>
> You are right. Actually it is useless to load both modules at the  
> same time and
> so this shouldn't be a problem. But better be safe. I'll resend this patch as
> well.

Thing is that since both have MODULE_ALIAS(serpent), they both get  
loaded with 'modprobe serpent' etc.

> > Actually about duplicating glue code.. is it really needed? On
> > x86_64, both avx and sse2 versions process 8-blocks parallel and
> > therefore glue code could be easily shared (as is done in SHA1
> > SSSE3/AVX).
>
> I thought about doing it the way as it is done in the SHA1-Module.  
> But I don't
> think that's a good idea, because then I had to compile both  
> implementations in
> the same module and decide at runtime which one to use depending on the
> processor capabilities. This would result in an increasing object  
> size and on a
> specific processor only one implementation is used. I think it's better to
> decide statically at compile-time which implementation to use.
> I agree, the code duplication is ugly, and have a different approach. All the
> glue code shared by both implementations can be moved to a  
> serpent_common_glue.c
> file and only the module init stuff needs to be seperate. This should reduce
> the code size and keeps the possibility of compiling only one  
> implementation. I
> will send a second patch which should do the job.

Looks better.

Maybe later when I have time, I'll check if all glue code for 16-byte  
block-ciphers found in arch/x86/crypto could be merged in to single  
helper module.

-Jussi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/