[fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)

[Niels de Vos]

On Mon, May 23, 2011 at 3:15 PM, Gordan Bobic <gordan at bobich.net> wrote:
> omalleys at msu.edu wrote:
>> Quoting Gordan Bobic <gordan at bobich.net>:
>>
>>> On 05/22/2011 09:17 AM, Peter Robinson wrote:
>>>> On Sun, May 22, 2011 at 2:11 AM, Gordan Bobic<gordan at bobich.net>  wrote:
>>>>> Hi,
>>>>>
>>>>> In case anyone is interested, I got this working on F13. It required
>>>>> building the cryptodev kernel module and rebuilding the standard F13
>>>>> OpenSSL package with three additional parameters (the cryptodev support
>>>>> is already in the standard OpenSSL package sources, it just isn't
>>>>> enabled in the default build).
>>>>>
>>>>> More details available here:
>>>>> http://www.altechnative.net/?p=174
>>>>>
>>>>> Any chance we can have cryptodev enabled in the standard package build?
>>>>> I cannot see any drawbacks to having it available - when cryptodev
>>>>> device isn't there, it will simply fall back to the software
>>>>> implementation. (Note: required cryptodev header file provided by the
>>>>> external kernel driver).
>>>>
>>>> We use upstream Fedora mainline packages. File a bug and once its
>>>> enabled in Fedora it will come to the ARM platform too.
>>>
>>> Filed:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=706706
>>
>> That just rocks, Thanks!!
>
> Yeah, it's pretty awesome. It makes the Sheevaplug catch up with the
> Atom that is 466MHz faster and 4x more power-hungry.
>
> What I'm pondering now is something like a dkms package for the
> cryptodev kernel module, but I seem to remember reading somewhere that
> dkms is a non-Fedora RHEL thing. What do you guys think would be the
> best way to approach it, especially since we don't have "standard"
> kernels at the moment?

>From my understanding, these are the options in their assumed preferred order:

1) integration in the upstream kernel
- Without this, is it not likely that a kernel in a standard Fedora
repository will have cryptodev by default
- How likely the inclusion is depends on both upstream for cryptodev
and the linux kernel

2) kmod packages that provide the .ko file(s) for a series of kernel releases
- obsoleted standard as modules should be included upstream
- http://fedoraproject.org/wiki/Obsolete/KernelModules
- compatible with a series of built kernels (kABI-compatible)
- there is no Fedora ARM kernel package that can be compatible

3) DKMS from http://linux.dell.com/dkms/dkms.html
- compiles modules on boot if the module is not available
- compiles against the running kernel
- several issues, like the need of kernel-headers and a suitable
compiler on the system

So, 1) is not an option yet from my understanding. 2) requires a
packaged kernel and all users should use that same kernel, which is
not the case at the moment either. This leaves 3) as only solution...

HTH,
Niels