Re: [Ocf-linux-users] OCF inbuilt and 2.6.27

[David M. <Dav...@se...>]

Jivin Daniel Mueller lays it down ...
> On Mon, 16 Mar 2009 16:41:12 +1000 David McCullough wrote:
> 
> > OCF is not moving into the kernel,  not ever.  The licensing was one
> > of the major stumbing blocks.
> 
> I have just checked kernel 2.6.28.7 and I found (native) drivers for
> 
> - VIA's Padlock
> - AMD's Geode AES engine
> - Intel's IXP4xx NPE-C
> - Freescale's Integrated Security Engine (talitos)
> - HIFN 795x crypto accelerator
> 
> That's definitely more than two years ago.

Absolutely,  and the crypto guys a fixing stuff all the time.  A
serialised async ipsec patch was posted today.  All of this native
linux crypto is slowly coming together.

> I am now asking myself why not write native Linux drivers instead of
> OCF modules and use the cryptodev (/dev/crypto) interface only?

There is nothing wrong with that approach at all,  and if linux is your
focus,  and you would like your work to be mainlined, thats the only
approach to chose.

> I have
> read the OCF documentation and I know that David would like other OS
> projects (e.g. OpenBSD or FreeBSD) to benefit from new/improved
> drivers.

There were lots of reasons OCF never had a chance to make it into the
kernel.  Firstly, the licensing,  and since I reused so much of the OCF
code there was no way I could change the license without permission from
all the listed authors.  Understandably a number of them refused to
allow it to be released under a Dual BSD/GPL license.  So it had to
stick with BSD.

> I can hardly imagine that new drivers can be adopted without
> porting efforts.

Yes,  but the porting is purely at the HW level,  all the "API" bits
stay the same.

> I myself would rather write a native driver and distribute it with
> dual license (GPL/BSD). The only reason I didn't managed it yet was the
> lack of documentation of Linux's async crypto API ;-)

Use the talitos driver as an example.  From what I have seen it should
be fairly easy to follow.

> A native driver could be used for
> - kernel IPSec
> - luks/dm-crypt
> - ..
> 
> The cryptodev/cryptosoft interface is still needed for user space
> applications such as OpenSSL. If those two parts where GPL licensed 
> the acceptance for kernel inclusion could raise. Or do I forget
> something important here?

There have already be patches posted for a kernel crypto API user
interface,  however,  there is a tendancy to avoid it,  even if it isn't
OCF.  Just the linux-crypto mailing list or look through the archives
for all the OCF and other user mode interface discussions.

Current thinking is that they would rather move the bulk crypto into the
kernel as a full SSL socket type than use an user-kernel API to do the
crypto.  This is good in that it gives you really high performance SSL
connections,  downside is that you have to wait for it to arrive ;-)

In the interim,  using cryptosoft and cryptodev with native kernel
crypto drivers is an easy way to keep working while they sort it out,

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org