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

Wed Oct 31 17:11:11 UTC 2012

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 does definitely accelerate openssl when properly used in both the
kernel and
userspace, but I'm not seeing the full offload kernel framework anywhere.

I wonder if anyone actually uses it :)

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

Bruce

>
> -M
>
> >
> > Cheers,
> >
> > Bruce
> >
> >
> >>
> >> Signed-off-by: Yashpal Dutta <yashpal.dutta at freescale.com>
> >> ---
> >>  meta/recipes-kernel/cryptodev/cryptodev_1.5.bb     |   18
> +++++++++++++
> >>  .../cryptodev/files/makefile_fixup.patch           |   26
> ++++++++++++++++++++
> >>  2 files changed, 44 insertions(+), 0 deletions(-)
> >>  create mode 100644 meta/recipes-kernel/cryptodev/cryptodev_1.5.bb
> >>  create mode 100644
> meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
> >>
> >> diff --git a/meta/recipes-kernel/cryptodev/cryptodev_1.5.bbb/meta/recipes-kernel/cryptodev/
> cryptodev_1.5.bb
> >> new file mode 100644
> >> index 0000000..5125710
> >> --- /dev/null
> >> +++ b/meta/recipes-kernel/cryptodev/cryptodev_1.5.bb
> >> @@ -0,0 +1,18 @@
> >> +SECTION = "devel"
> >> +SUMMARY = "Linux Cryptodev KERNEL MODULE"
> >> +DESCRIPTION = "The Cryptodev package contains the kernel /dev/crypto
> module"
> >> +LICENSE = "GPLv2"
> >> +LIC_FILES_CHKSUM =
> "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> >> +
> >> +DEPENDS = "virtual/kernel"
> >> +
> >> +inherit module
> >> +
> >> +SRCREV = "1c24a0aa996630518d47826a2e3fea129ea094c7"
> >> +
> >> +SRC_URI = "git://repo.or.cz/cryptodev-linux.git;protocol=git \
> >> +         file://makefile_fixup.patch"
> >> +
> >> +EXTRA_OEMAKE='KERNEL_DIR="${STAGING_KERNEL_DIR}" PREFIX="${D}"'
> >> +
> >> +S = "${WORKDIR}/git"
> >> diff --git a/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
> b/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
> >> new file mode 100644
> >> index 0000000..323aacd
> >> --- /dev/null
> >> +++ b/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
> >> @@ -0,0 +1,26 @@
> >> +diff --git a/Makefile b/Makefile
> >> +index 2be8825..b36d68c 100644
> >> +--- a/Makefile
> >> ++++ b/Makefile
> >> +@@ -1,6 +1,7 @@
> >> + KBUILD_CFLAGS += -I$(src)
> >> + KERNEL_DIR = /lib/modules/$(shell uname -r)/build
> >> + VERSION = 1.5
> >> ++PREFIX =
> >> +
> >> + cryptodev-objs = ioctl.o main.o cryptlib.o authenc.o zc.o util.o
> >> +
> >> +@@ -12,10 +13,10 @@ build: version.h
> >> + version.h: Makefile
> >> +       @echo "#define VERSION \"$(VERSION)\"" > version.h
> >> +
> >> +-install:
> >> ++modules_install:
> >> +       make -C $(KERNEL_DIR) SUBDIRS=`pwd` modules_install
> >> +-      @echo "Installing cryptodev.h in /usr/include/crypto ..."
> >> +-      @install -D crypto/cryptodev.h /usr/include/crypto/cryptodev.h
> >> ++      @echo "Installing cryptodev.h in $(PREFIX)/usr/include/crypto
> ..."
> >> ++      @install -D crypto/cryptodev.h
> $(PREFIX)/usr/include/crypto/cryptodev.h
> >> +
> >> + clean:
> >> +       make -C $(KERNEL_DIR) SUBDIRS=`pwd` clean
> >> --
> >> 1.7.0.4
> >>
> >>
> >>
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core at lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> >
> >
> > --
> > "Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end"
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core at lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20121031/e8d3a747/attachment-0002.html>