Herbert Xu wrote:
Hi Michal:
On Thu, May 25, 2006 at 09:27:20AM +1200, Michal Ludvig wrote:
It's not a rocket science. It does, however, introduce backward
incompatibility. But I don't think that would be a problem - it's a
module only for testing anyway.
I like the concept. But I think you should be more audacious :)
How about making tcrypt modularised? What I'd like to see is a model
where each crypto algorithm can provide its own test vectors that
produces its own module. For instance, to test AES I'd do something
like 'modprobe aes-tcrypt <params>'.
This way we will no longer have the ever growing tcrypt.[ch] that are
starting to look scary.
This is a testing module only. Who use it? I guess just developers when
working on crypto stuff - they (we) won't be scaried by the ever growing
tcrypt.[ch] I guess.
Honestly, I'm not likely to spend two days copy&pasting existing test
vectors all around linux/crypto just for those five or ten people who
are likely to insmod tcrypt.ko in next half a year ;-)
Even if you accept my patch as it is you can still modularize it later ;-)
BTW how about the digest-speed thing?
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
