On Tue, Oct 30, 2012 at 2:50 PM, McClintock Matthew-B29882 < [email protected]> wrote:
> On Thu, Oct 18, 2012 at 8:33 AM, Bruce Ashfield > <[email protected]> wrote: > > On Thu, Oct 18, 2012 at 5:57 AM, Yashpal Dutta > > <[email protected]> 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 <[email protected]> > >> --- > >> 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 > >> [email protected] > >> 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 > > [email protected] > > 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 [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
