<br><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 30, 2012 at 2:50 PM, McClintock Matthew-B29882 <span dir="ltr"><<a href="mailto:B29882@freescale.com" target="_blank">B29882@freescale.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>On Thu, Oct 18, 2012 at 8:33 AM, Bruce Ashfield<br>
<<a href="mailto:bruce.ashfield@gmail.com" target="_blank">bruce.ashfield@gmail.com</a>> wrote:<br>
> On Thu, Oct 18, 2012 at 5:57 AM, Yashpal Dutta<br>
> <<a href="mailto:yashpal.dutta@freescale.com" target="_blank">yashpal.dutta@freescale.com</a>> wrote:<br>
>> This is a /dev/crypto device driver, equivalent to those in OpenBSD or FreeBSD.<br>
>> The main idea is to access of existing ciphers in kernel space from userspace,<br>
>> thus enabling re-use of a hardware implementation of a cipher.<br>
><br>
> I always use OCF for an overlapping set of functionality. To make this external<br>
> module gracefully deal with a situation such as this, maybe a check for OCF<br>
> in the kernel config ?<br>
><br>
> The same thing could be said about having a kernel with this functionality<br>
> already integrated (I have several of those as well).<br>
><br>
> That's a more general question about what's the best way to gracefully deal<br>
> with out of tree modules detecting that they are being built against a kernel<br>
> that already has the functionality merged. The easy answer is that<br>
> it's something<br>
> the distro maintainer needs to know, and manage, and maybe that's the<br>
> final answer. But I'm more wondering about this with respect to<br>
> inter-operability<br>
> of layers, if something in a layer depends/rdepends on this module, it will be<br>
> pulled in, and won't that limit the mix/match/stacking of the various layers ?<br>
><br>
> I added Richard for comment on the above.<br>
><br>
> But that of course raises the question, why should this be in oe-core versus<br>
> something like OCF ? This is definitely simpler, but OCF has it's use cases and<br>
> advantages as well, that are an overlapping set of functionality.<br>
><br>
> I don't have all the answers, just plenty of questions :)<br>
<br>
</div></div>I'm not overly familiar with OCF. Does this just RCONFLICT with ocf-linux?<br></blockquote><div><br></div><div>I missed this yesterday, sorry about that. gmail just left this in the thread and</div><div>not in my inbox .. but anyway.</div>
<div><br></div><div>I only see parts ocf in oe-core, but maybe I'm just not understanding what the</div><div>recipe is doing (are you seeing more) ? i.e. ocf-linux is buried under the </div><div>open-ssl recipe, and really looks to be just providing headers. </div>
<div><br></div><div>I'm doing some builds now to learn more .. which I just did .. and from what I <br></div><div>can see, it is just the headers, which isn't all that useful without the kernel</div><div>underpinning. </div>
<div><br></div><div><div>OCF does definitely accelerate openssl when properly used in both the kernel and</div><div>userspace, but I'm not seeing the full offload kernel framework anywhere.</div></div><div><br></div><div>
I wonder if anyone actually uses it :)</div>
<div><br></div><div>But yes AFAIC, if you had a full OCF, you need these to conflict, since they'll both </div><div>try and enable/provide cryptodev.</div><div><br></div><div>Bruce</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><font color="#888888"><br>
-M<br>
</font></span><div><div><br>
><br>
> Cheers,<br>
><br>
> Bruce<br>
><br>
><br>
>><br>
>> Signed-off-by: Yashpal Dutta <<a href="mailto:yashpal.dutta@freescale.com" target="_blank">yashpal.dutta@freescale.com</a>><br>
>> ---<br>
>> meta/recipes-kernel/cryptodev/<a href="http://cryptodev_1.5.bb" target="_blank">cryptodev_1.5.bb</a> | 18 +++++++++++++<br>
>> .../cryptodev/files/makefile_fixup.patch | 26 ++++++++++++++++++++<br>
>> 2 files changed, 44 insertions(+), 0 deletions(-)<br>
>> create mode 100644 meta/recipes-kernel/cryptodev/<a href="http://cryptodev_1.5.bb" target="_blank">cryptodev_1.5.bb</a><br>
>> create mode 100644 meta/recipes-kernel/cryptodev/files/makefile_fixup.patch<br>
>><br>
>> diff --git a/meta/recipes-kernel/cryptodev/<a href="http://cryptodev_1.5.bb" target="_blank">cryptodev_1.5.bb</a> b/meta/recipes-kernel/cryptodev/<a href="http://cryptodev_1.5.bb" target="_blank">cryptodev_1.5.bb</a><br>
>> new file mode 100644<br>
>> index 0000000..5125710<br>
>> --- /dev/null<br>
>> +++ b/meta/recipes-kernel/cryptodev/<a href="http://cryptodev_1.5.bb" target="_blank">cryptodev_1.5.bb</a><br>
>> @@ -0,0 +1,18 @@<br>
>> +SECTION = "devel"<br>
>> +SUMMARY = "Linux Cryptodev KERNEL MODULE"<br>
>> +DESCRIPTION = "The Cryptodev package contains the kernel /dev/crypto module"<br>
>> +LICENSE = "GPLv2"<br>
>> +LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"<br>
>> +<br>
>> +DEPENDS = "virtual/kernel"<br>
>> +<br>
>> +inherit module<br>
>> +<br>
>> +SRCREV = "1c24a0aa996630518d47826a2e3fea129ea094c7"<br>
>> +<br>
>> +SRC_URI = "git://<a href="http://repo.or.cz/cryptodev-linux.git;protocol=git" target="_blank">repo.or.cz/cryptodev-linux.git;protocol=git</a> \<br>
>> + file://makefile_fixup.patch"<br>
>> +<br>
>> +EXTRA_OEMAKE='KERNEL_DIR="${STAGING_KERNEL_DIR}" PREFIX="${D}"'<br>
>> +<br>
>> +S = "${WORKDIR}/git"<br>
>> diff --git a/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch b/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch<br>
>> new file mode 100644<br>
>> index 0000000..323aacd<br>
>> --- /dev/null<br>
>> +++ b/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch<br>
>> @@ -0,0 +1,26 @@<br>
>> +diff --git a/Makefile b/Makefile<br>
>> +index 2be8825..b36d68c 100644<br>
>> +--- a/Makefile<br>
>> ++++ b/Makefile<br>
>> +@@ -1,6 +1,7 @@<br>
>> + KBUILD_CFLAGS += -I$(src)<br>
>> + KERNEL_DIR = /lib/modules/$(shell uname -r)/build<br>
>> + VERSION = 1.5<br>
>> ++PREFIX =<br>
>> +<br>
>> + cryptodev-objs = ioctl.o main.o cryptlib.o authenc.o zc.o util.o<br>
>> +<br>
>> +@@ -12,10 +13,10 @@ build: version.h<br>
>> + version.h: Makefile<br>
>> + @echo "#define VERSION \"$(VERSION)\"" > version.h<br>
>> +<br>
>> +-install:<br>
>> ++modules_install:<br>
>> + make -C $(KERNEL_DIR) SUBDIRS=`pwd` modules_install<br>
>> +- @echo "Installing cryptodev.h in /usr/include/crypto ..."<br>
>> +- @install -D crypto/cryptodev.h /usr/include/crypto/cryptodev.h<br>
>> ++ @echo "Installing cryptodev.h in $(PREFIX)/usr/include/crypto ..."<br>
>> ++ @install -D crypto/cryptodev.h $(PREFIX)/usr/include/crypto/cryptodev.h<br>
>> +<br>
>> + clean:<br>
>> + make -C $(KERNEL_DIR) SUBDIRS=`pwd` clean<br>
>> --<br>
>> 1.7.0.4<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Openembedded-core mailing list<br>
>> <a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
>> <a href="http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core" target="_blank">http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core</a><br>
><br>
><br>
><br>
> --<br>
> "Thou shalt not follow the NULL pointer, for chaos and madness await<br>
> thee at its end"<br>
><br>
> _______________________________________________<br>
> Openembedded-core mailing list<br>
> <a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
> <a href="http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core" target="_blank">http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"<br>
</div>