On Wed, Oct 31, 2012 at 12:11 PM, Bruce Ashfield <bruce.ashfi...@gmail.com> wrote: > > On Tue, Oct 30, 2012 at 2:50 PM, McClintock Matthew-B29882 > <b29...@freescale.com> wrote: >> >> On Thu, Oct 18, 2012 at 8:33 AM, Bruce Ashfield >> <bruce.ashfi...@gmail.com> wrote: >> > On Thu, Oct 18, 2012 at 5:57 AM, Yashpal Dutta >> > <yashpal.du...@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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core