On Mon, May 23, 2011 at 3:15 PM, Gordan Bobic <gordan(a)bobich.net> wrote:
> Quoting Gordan Bobic <gordan(a)bobich.net>:
>> On 05/22/2011 09:17 AM, Peter Robinson wrote:
>>> On Sun, May 22, 2011 at 2:11 AM, Gordan Bobic<gordan(a)bobich.net>
>>>> 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:
>>>> 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.
> 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
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
- 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...