Re: Hardware Crypto Offload on Kirkwood (SheevaPlug)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 23, 2011 at 3:15 PM, Gordan Bobic <gordan@xxxxxxxxxx> wrote:
> omalleys@xxxxxxx wrote:
>> Quoting Gordan Bobic <gordan@xxxxxxxxxx>:
>>
>>> On 05/22/2011 09:17 AM, Peter Robinson wrote:
>>>> On Sun, May 22, 2011 at 2:11 AM, Gordan Bobic<gordan@xxxxxxxxxx> Â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
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM (Vger)]     [Linux ARM]     [ARM Kernel]     [Fedora User Discussion]     [Older Fedora Users Discussion]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux