omalleys(a)msu.edu 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>
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?
Good question. Although I thought dkms support was recently added like F13.
My question, is how hard is this to implement the hardware support
non-openssl programs. OpenAFS could use this as it can use a lot of
DES encryption, but it uses its own DES implementation. It also
happens to be the only one I can think of off the top of my head that
uses its own implementation. It would be nice to have.