[OE-core] [PATCH] cryptodev kernel module recipe

[McClintock Matthew-B29882]

On Wed, Oct 31, 2012 at 12:11 PM, Bruce Ashfield
<bruce.ashfield at gmail.com> wrote:
>
> On Tue, Oct 30, 2012 at 2:50 PM, McClintock Matthew-B29882
> <B29882 at freescale.com> wrote:
>>
>> On Thu, Oct 18, 2012 at 8:33 AM, Bruce Ashfield
>> <bruce.ashfield at gmail.com> wrote:
>> > On Thu, Oct 18, 2012 at 5:57 AM, Yashpal Dutta
>> > <yashpal.dutta at freescale.com> wrote:
>> >> This is a /dev/crypto device driver, equivalent to those in OpenBSD or
>> >> FreeBSD.
>> >> The main idea is to access of existing ciphers in kernel space from
>> >> userspace,
>> >> thus enabling re-use of a hardware implementation of a cipher.
>> >
>> > I always use OCF for an overlapping set of functionality. To make this
>> > external
>> > module gracefully deal with a situation such as this, maybe a check for
>> > OCF
>> > in the kernel config ?
>> >
>> > The same thing could be said about having a kernel with this
>> > functionality
>> > already integrated (I have several of those as well).
>> >
>> > That's a more general question about what's the best way to gracefully
>> > deal
>> > with out of tree modules detecting that they are being built against a
>> > kernel
>> > that already has the functionality merged. The easy answer is that
>> > it's something
>> > the distro maintainer needs to know, and manage, and maybe that's the
>> > final answer. But I'm more wondering about this with respect to
>> > inter-operability
>> > of layers, if something in a layer depends/rdepends on this module, it
>> > will be
>> > pulled in, and won't that limit the mix/match/stacking of the various
>> > layers ?
>> >
>> > I added Richard for comment on the above.
>> >
>> > But that of course raises the question, why should this be in oe-core
>> > versus
>> > something like OCF ? This is definitely simpler, but OCF has it's use
>> > cases and
>> > advantages as well, that are an overlapping set of functionality.
>> >
>> > I don't have all the answers, just plenty of questions :)
>>
>> I'm not overly familiar with OCF. Does this just RCONFLICT with ocf-linux?
>
>
> I missed this yesterday, sorry about that. gmail just left this in the
> thread and
> not in my inbox .. but anyway.
>
> I only see parts ocf in oe-core, but maybe I'm just not understanding what
> the
> recipe is doing (are you seeing more) ? i.e. ocf-linux is buried under the
> open-ssl recipe, and really looks to be just providing headers.
>
> I'm doing some builds now to learn more .. which I just did .. and from what
> I
> can see, it is just the headers, which isn't all that useful without the
> kernel
> underpinning.

ocf-linux recipe does infact appear to be just headers. As far as what
it's used for I'm not even sure. I'll ask the crypto guys to chime in
here.

> OCF does definitely accelerate openssl when properly used in both the kernel
> and
> userspace, but I'm not seeing the full offload kernel framework anywhere.

Can't comment what others do, it would be ideal if we got all users
talking here though.

> I wonder if anyone actually uses it :)

Good question, it was added by Saul so maybe he can chime in here.

> But yes AFAIC, if you had a full OCF, you need these to conflict, since
> they'll both
> try and enable/provide cryptodev.

Yashpal,

You should to add

RCONFLICTS_${PN} = "ocf-linux"

and/or maybe

RCONFLICTS_${PN}-dev = "ocf-linux-dev"

to your v2 of the patch.

-M