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

[Bruce Ashfield]

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 :)

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.bb b/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"