Hi Michael, On Fri, Aug 05, 2016 at 07:23:38PM +0200, Michael Weiser wrote: > On Fri, Aug 05, 2016 at 01:13:44PM +0200, Michael Weiser wrote: > > > > If you care to provide a patch, I'd happily test/review it. > > > I'll give it a whirl and report back. > > I've done some groundwork, mostly research through a well known search > engine and in the kernel code. What I've found is now at > https://github.com/michaelweiser/cryptodev-linux/commit/30e66ed072d34ad0ca93f7457a9772519ca68de0.
Looks pretty reasonable. The only thing I would worry about is the dropped checks in lines 210 and 228. Was there a specific reason for that? > It compiles but I haven't had a chance to actually test it for function > yet. Well, after compiling and loading the module, you could run the tests in test/ subdir (note how I subtly try to push you into testing). > It turns out skcipher is fairly young: It entered mainline with 4.3. Well, from a kernel's perspective that's not really young. But that they deprecate the old API already means they have full trust in the new one, which is a good sign. > What is your take on supporting old kernel versions: Should I #ifdef for > < 4.3 or can I just drop ablkcipher like I've done now? Yes, sadly we have to support older kernels as well (see existing compat code). That's the curse of out-of-tree modules, I fear. > BTW: I've looked into > https://github.com/cryptodev-linux/cryptodev-linux/issues/12 more > closely to get cryptodev-linux to compile against current master. > Moonman's proposed fix > (https://github.com/cryptodev-linux/cryptodev-linux/pull/13/commits/cdbe7ee5978704c788e91170467fe0db064650fe) > seemed too good to be true to me. I came up with > https://github.com/michaelweiser/cryptodev-linux/commit/70f3aff97fc44079afcb2cc058c37bba320c5a57. > Does that look sensible to you? That's actually part of my backlog. :( Thanks, Phil _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
