Hi, I'd like to add simple support to cryptoapi for a certain on-cpu hardware encryption unit. There seem to be no current hardware API in cryptoapi, but doing at least a semi hackish job of seems not too hard: just define a `cipher_implementation' with appropriate methods that invoke the hardware. My question is about the `_atomic' variants (e.g. encrypt_atomic) -- the IPSEC implementation only uses these so it seems necessary to implement them, but the definition of `struct cipher_implementation' contains a comment which says that "atomic" implies both `will never sleep' and `always SW implementation'. I'm wondering why the documentation includes the `always SW implementation' constraint. In my case, using hardware seems safe enough because: * The hardware in question seems reasonably fast (17 cycles for a DES block encryption), so it doesn't seem a problem not to sleep -- it should be faster than the SW implementation anyway (er, I think, anyway, from looking at the routines). * Though the encryption hardware is stateful, as long as my encryption/etc routines are never invoked from an interrupt context, I can just sure things are set up correctly and assume I have sole access until I return (SMP shouldn't be an issue because it's an on-CPU unit, and anyway probably nobody would ever use this CPU in such a configuration :-) So I'm hoping I can just treat this as a funny CPU instruction and do the simple thing. E.g. put BUG_ON (in_interrupt()) in my routines, etc. Can anybody offer advice about this? Am I safe assuming I won't get called from an interrupt context? Are there other pitfalls I don't see? Apologies if this seems clueless, I just started looking at this stuff... Thanks, -Miles -- I'm beginning to think that life is just one long Yoko Ono album; no rhyme or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
