> In the current implementation, getting a version that doesn't sleep > simply requires disabling the if (current->need_reshed) test. This Is this enough? Sleeping can be achieved e.g. by sleep_on() which is a common way for drivers, and calling this in an interrupt context already causes a kernel panic. If we want to use the cipher in this way we must have some means to either tell the cipher to never ever sleep, or to have the cipher tell us whether it _can_ sleep (and then reject to use it; to the user this behaviour is nonobvious and it does not look good to have a cipher work or not depending on how it's implemented). > However, in the future this means we always have to have a > software-version of any hardware-accellerated cipher, or _only_ > provide hardware-accelleration using a work-queue interface where we > invoke a callback when the job is done. Hm, didn't think about that. One easy possibility would be to put the output packets in the (existing) input queue and handle them in the ciped process context. However, this could increase packet output latency by a degree I just don't want to bear, and it will definitely interfere with any packet queuing mechanism the kernel employs itself. A kernel thread would have the same problems. A callback solution looks cleaner to me. A non sleeping software-only solution could do that too, to avoid dealing with a double API. Olaf Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
