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

> 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

Reply via email to