* [PATCH v2] cmem: Adding New recipe for cmem @ 2013-11-07 5:03 Sam Nelson 2013-11-07 7:35 ` Maupin, Chase 2013-11-20 13:11 ` Maupin, Chase 0 siblings, 2 replies; 17+ messages in thread From: Sam Nelson @ 2013-11-07 5:03 UTC (permalink / raw) To: meta-arago, sam.nelson - Cmem module is used for user space contiguous memory alloation Signed-off-by: Sam Nelson <sam.nelson@ti.com> --- recipes-bsp/cmem/cmem-mod_git.bb | 26 ++++++++++++++++++++++++++ recipes-bsp/cmem/cmem.inc | 12 ++++++++++++ recipes-bsp/cmem/cmem_git.bb | 16 ++++++++++++++++ 3 files changed, 54 insertions(+) create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb create mode 100644 recipes-bsp/cmem/cmem.inc create mode 100644 recipes-bsp/cmem/cmem_git.bb diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes-bsp/cmem/cmem-mod_git.bb new file mode 100644 index 0000000..c402b72 --- /dev/null +++ b/recipes-bsp/cmem/cmem-mod_git.bb @@ -0,0 +1,26 @@ +DESCRIPTION="Contiguous memory allocation kernel module for contiguous memory allocation from userspace " + +include cmem.inc + +NAME="cmem" + +# This package builds a kernel module, use kernel PR as base and append a local +PR = "${MACHINE_KERNEL_PR}" +PR_append = "a" + +PKG_${PN} = "kernel-module-${PN}" + +S = "${WORKDIR}/git" + +inherit module + +do_compile () { + cd ${S} + make -f lu.mak module_clean + make -f lu.mak module KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR} TOOLCHAIN_PREFIX=${CROSS_COMPILE} +} + +do_install () { + cd ${S} + make -f lu.mak module_install KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra" INSTALL_MOD_PATH="${D}" +} diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc new file mode 100644 index 0000000..5d17d8e --- /dev/null +++ b/recipes-bsp/cmem/cmem.inc @@ -0,0 +1,12 @@ +HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM" + +LICENSE = "GPLv2" +LIC_FILES_CHKSUM = "file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb8310b3b983024edc620" + +COMPATIBLE_MACHINE = "keystone-evm" + +BRANCH ?= "master" +#SRCREV = "4.00.00.06" +SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d" + +SRC_URI = "git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}" diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes-bsp/cmem/cmem_git.bb new file mode 100644 index 0000000..f415630 --- /dev/null +++ b/recipes-bsp/cmem/cmem_git.bb @@ -0,0 +1,16 @@ +DESCRIPTION="The cmem component supports contiguous memory allocation from userspace " + +include cmem.inc + +RDEPENDS_${PN} = "cmem-mod" + +S = "${WORKDIR}/git" + +PR = "r0" + +PACKAGES =+ "${PN}-test" + +FILES_${PN}-test = "${bindir}/*" + +inherit autotools + -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-07 5:03 [PATCH v2] cmem: Adding New recipe for cmem Sam Nelson @ 2013-11-07 7:35 ` Maupin, Chase 2013-11-07 11:49 ` Nelson, Sam 2013-11-20 13:11 ` Maupin, Chase 1 sibling, 1 reply; 17+ messages in thread From: Maupin, Chase @ 2013-11-07 7:35 UTC (permalink / raw) To: Nelson, Sam, meta-arago@arago-project.org >-----Original Message----- >From: meta-arago-bounces@arago-project.org [mailto:meta-arago- >bounces@arago-project.org] On Behalf Of Nelson, Sam >Sent: Thursday, November 07, 2013 10:34 AM >To: meta-arago@arago-project.org; Nelson, Sam >Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > >- Cmem module is used for user space contiguous memory alloation > >Signed-off-by: Sam Nelson <sam.nelson@ti.com> >--- > recipes-bsp/cmem/cmem-mod_git.bb | 26 >++++++++++++++++++++++++++ > recipes-bsp/cmem/cmem.inc | 12 ++++++++++++ > recipes-bsp/cmem/cmem_git.bb | 16 ++++++++++++++++ > 3 files changed, 54 insertions(+) > create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb > create mode 100644 recipes-bsp/cmem/cmem.inc > create mode 100644 recipes-bsp/cmem/cmem_git.bb This patch should be submitted to meta-ti@yoctoproject.org which is the meta-ti mailing list. > >diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes- >bsp/cmem/cmem-mod_git.bb >new file mode 100644 >index 0000000..c402b72 >--- /dev/null >+++ b/recipes-bsp/cmem/cmem-mod_git.bb >@@ -0,0 +1,26 @@ >+DESCRIPTION="Contiguous memory allocation kernel module for >contiguous memory allocation from userspace " >+ >+include cmem.inc >+ >+NAME="cmem" Not sure what the NAME variable is for >+ >+# This package builds a kernel module, use kernel PR as base and >append a local >+PR = "${MACHINE_KERNEL_PR}" >+PR_append = "a" >+ >+PKG_${PN} = "kernel-module-${PN}" I think what you are trying to do here is already handled by the package.bbclass. I assume you are trying to set the package name to kernel-module-cmem-mod? This raises the question of whether you want this to be cmem-mod for the recipe and PN or if you want cmem for the module and cmem-xyz for the libraries. >+ >+S = "${WORKDIR}/git" >+ >+inherit module >+ >+do_compile () { >+ cd ${S} >+ make -f lu.mak module_clean >+ make -f lu.mak module >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR} >TOOLCHAIN_PREFIX=${CROSS_COMPILE} You should use the default do_compile in the module.bbclass I think. You should be able to pass this with MAKE_TARGETS variable. >+} >+ >+do_install () { >+ cd ${S} >+ make -f lu.mak module_install >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra" >INSTALL_MOD_PATH="${D}" Hmmm. The default do_install for the module.bbclass uses "modules_install" instead of "module_install". If you can get the lu.mak file updated that would be ideal. If not then you should at least copy the base function which unsets some variables. >+} >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc >new file mode 100644 >index 0000000..5d17d8e >--- /dev/null >+++ b/recipes-bsp/cmem/cmem.inc >@@ -0,0 +1,12 @@ >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM" >+ >+LICENSE = "GPLv2" >+LIC_FILES_CHKSUM = >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb >8310b3b983024edc620" >+ >+COMPATIBLE_MACHINE = "keystone-evm" As Sidd pointed out is there any reason not to add the other devices like omap-a15 as compatible machines? >+ >+BRANCH ?= "master" >+#SRCREV = "4.00.00.06" Remove this comment but add one that the commit id below corresponds to release 4.00.00.06. Is there perhaps a value to having the version in the package name instead of using _git versions? Will all SDKs be in step with using the same version? >+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d" >+ >+SRC_URI = >"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}" >diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes- >bsp/cmem/cmem_git.bb >new file mode 100644 >index 0000000..f415630 >--- /dev/null >+++ b/recipes-bsp/cmem/cmem_git.bb >@@ -0,0 +1,16 @@ >+DESCRIPTION="The cmem component supports contiguous memory >allocation from userspace " >+ >+include cmem.inc >+ >+RDEPENDS_${PN} = "cmem-mod" >+ >+S = "${WORKDIR}/git" >+ >+PR = "r0" >+ >+PACKAGES =+ "${PN}-test" >+ >+FILES_${PN}-test = "${bindir}/*" As Denys pointed out last time, if everything goes into cmem-test then why not just call this whole recipe cmem-test since the base cmem package is empty. >+ >+inherit autotools >+ >-- >1.7.9.5 > >_______________________________________________ >meta-arago mailing list >meta-arago@arago-project.org >http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-07 7:35 ` Maupin, Chase @ 2013-11-07 11:49 ` Nelson, Sam 2013-11-08 0:33 ` Tivy, Robert 2013-11-08 1:53 ` Denys Dmytriyenko 0 siblings, 2 replies; 17+ messages in thread From: Nelson, Sam @ 2013-11-07 11:49 UTC (permalink / raw) To: Maupin, Chase, meta-arago@arago-project.org; +Cc: Ring, Chris, Tivy, Robert > -----Original Message----- > From: Maupin, Chase > Sent: Thursday, November 07, 2013 2:35 AM > To: Nelson, Sam; meta-arago@arago-project.org > Subject: RE: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > >-----Original Message----- > >From: meta-arago-bounces@arago-project.org [mailto:meta-arago- > >bounces@arago-project.org] On Behalf Of Nelson, Sam > >Sent: Thursday, November 07, 2013 10:34 AM > >To: meta-arago@arago-project.org; Nelson, Sam > >Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > >- Cmem module is used for user space contiguous memory alloation > > > >Signed-off-by: Sam Nelson <sam.nelson@ti.com> > >--- > > recipes-bsp/cmem/cmem-mod_git.bb | 26 > >++++++++++++++++++++++++++ > > recipes-bsp/cmem/cmem.inc | 12 ++++++++++++ > > recipes-bsp/cmem/cmem_git.bb | 16 ++++++++++++++++ > > 3 files changed, 54 insertions(+) > > create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb > > create mode 100644 recipes-bsp/cmem/cmem.inc > > create mode 100644 recipes-bsp/cmem/cmem_git.bb > > This patch should be submitted to meta-ti@yoctoproject.org which is the > meta-ti mailing list. [Sam] Ok. I will do that. > > > > >diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes- > >bsp/cmem/cmem-mod_git.bb > >new file mode 100644 > >index 0000000..c402b72 > >--- /dev/null > >+++ b/recipes-bsp/cmem/cmem-mod_git.bb > >@@ -0,0 +1,26 @@ > >+DESCRIPTION="Contiguous memory allocation kernel module for > >contiguous memory allocation from userspace " > >+ > >+include cmem.inc > >+ > >+NAME="cmem" > > Not sure what the NAME variable is for [Sam] I am not sure either. This is probably because of initial template used for creation of the recipe. I can remove it if this really not needed. > > >+ > >+# This package builds a kernel module, use kernel PR as base and > >append a local > >+PR = "${MACHINE_KERNEL_PR}" > >+PR_append = "a" > >+ > >+PKG_${PN} = "kernel-module-${PN}" > > I think what you are trying to do here is already handled by the > package.bbclass. I assume you are trying to set the package name to kernel- > module-cmem-mod? > > This raises the question of whether you want this to be cmem-mod for the > recipe and PN or if you want cmem for the module and cmem-xyz for the > libraries. > [Sam] I guess the alternative you are suggesting is cmem for the module and cmem-lib for the libraries. I am not seeing a compelling reason to change. > >+ > >+S = "${WORKDIR}/git" > >+ > >+inherit module > >+ > >+do_compile () { > >+ cd ${S} > >+ make -f lu.mak module_clean > >+ make -f lu.mak module > >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR} > >TOOLCHAIN_PREFIX=${CROSS_COMPILE} > > You should use the default do_compile in the module.bbclass I think. You > should be able to pass this with MAKE_TARGETS variable. [Sam] Probably Chris and Rob on the CC list can comment on this. This will need change of the module. > > >+} > >+ > >+do_install () { > >+ cd ${S} > >+ make -f lu.mak module_install > >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" > >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra" > >INSTALL_MOD_PATH="${D}" > > Hmmm. The default do_install for the module.bbclass uses > "modules_install" instead of "module_install". If you can get the lu.mak file > updated that would be ideal. If not then you should at least copy the base > function which unsets some variables. > [Sam] Probably Chris and Rob on the CC list can comment on this. This will need change of the module. > >+} > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc > >new file mode 100644 > >index 0000000..5d17d8e > >--- /dev/null > >+++ b/recipes-bsp/cmem/cmem.inc > >@@ -0,0 +1,12 @@ > >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM" > >+ > >+LICENSE = "GPLv2" > >+LIC_FILES_CHKSUM = > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb > >8310b3b983024edc620" > >+ > >+COMPATIBLE_MACHINE = "keystone-evm" > > As Sidd pointed out is there any reason not to add the other devices like > omap-a15 as compatible machines? [Sam] I am fine with remove the compatible machine. Although this is not tested with other machines. > >+ > >+BRANCH ?= "master" > >+#SRCREV = "4.00.00.06" > > Remove this comment but add one that the commit id below corresponds to > release 4.00.00.06. > [Sam] I will fix this. > Is there perhaps a value to having the version in the package name instead of > using _git versions? Will all SDKs be in step with using the same version? > [Sam] Chris or Rob, can you comment on this. I am not sure of when the other verticals pick up CMEM. > >+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d" > >+ > >+SRC_URI = > >"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}" > >diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes- > >bsp/cmem/cmem_git.bb > >new file mode 100644 > >index 0000000..f415630 > >--- /dev/null > >+++ b/recipes-bsp/cmem/cmem_git.bb > >@@ -0,0 +1,16 @@ > >+DESCRIPTION="The cmem component supports contiguous memory > >allocation from userspace " > >+ > >+include cmem.inc > >+ > >+RDEPENDS_${PN} = "cmem-mod" > >+ > >+S = "${WORKDIR}/git" > >+ > >+PR = "r0" > >+ > >+PACKAGES =+ "${PN}-test" > >+ > >+FILES_${PN}-test = "${bindir}/*" > > As Denys pointed out last time, if everything goes into cmem-test then why > not just call this whole recipe cmem-test since the base cmem package is > empty. [Sam] The cmem package has the library that goes into cmem-dev. And hence the name cmem. cmem-test will have the example/unit test code binaries. Only thing is there is no binary files associated with the cmem package itself. > > >+ > >+inherit autotools > >+ > >-- > >1.7.9.5 > > > >_______________________________________________ > >meta-arago mailing list > >meta-arago@arago-project.org > >http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-07 11:49 ` Nelson, Sam @ 2013-11-08 0:33 ` Tivy, Robert 2013-11-08 2:02 ` Denys Dmytriyenko 2013-11-08 1:53 ` Denys Dmytriyenko 1 sibling, 1 reply; 17+ messages in thread From: Tivy, Robert @ 2013-11-08 0:33 UTC (permalink / raw) To: Nelson, Sam, Maupin, Chase, meta-arago@arago-project.org; +Cc: Ring, Chris Please see my comments inline below... Regards, - Rob > -----Original Message----- > From: Nelson, Sam > Sent: Thursday, November 07, 2013 3:50 AM > To: Maupin, Chase; meta-arago@arago-project.org > Cc: Ring, Chris; Tivy, Robert > Subject: RE: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > ... > > > >+ > > >+S = "${WORKDIR}/git" > > >+ > > >+inherit module > > >+ > > >+do_compile () { > > >+ cd ${S} > > >+ make -f lu.mak module_clean > > >+ make -f lu.mak module > > >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR} > > >TOOLCHAIN_PREFIX=${CROSS_COMPILE} > > > > You should use the default do_compile in the module.bbclass I think. > You > > should be able to pass this with MAKE_TARGETS variable. > [Sam] Probably Chris and Rob on the CC list can comment on this. This > will need change of the module. Can you please explain the change needed? I'm not familiar with do_compile(). > > > > >+} > > >+ > > >+do_install () { > > >+ cd ${S} > > >+ make -f lu.mak module_install > > >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" > > >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra" > > >INSTALL_MOD_PATH="${D}" > > > > Hmmm. The default do_install for the module.bbclass uses > > "modules_install" instead of "module_install". If you can get the > lu.mak file > > updated that would be ideal. If not then you should at least copy > the base > > function which unsets some variables. > > > [Sam] Probably Chris and Rob on the CC list can comment on this. This > will need change of the module. This should be fine, I will make a change to lu.mak and commit to ludev.git. How about module_clean? Should that be changed to modules_clean? > > Is there perhaps a value to having the version in the package name > instead of > > using _git versions? Will all SDKs be in step with using the same > version? > > > [Sam] Chris or Rob, can you comment on this. I am not sure of when the > other verticals pick up CMEM. I need to let Chris comment on this. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-08 0:33 ` Tivy, Robert @ 2013-11-08 2:02 ` Denys Dmytriyenko 0 siblings, 0 replies; 17+ messages in thread From: Denys Dmytriyenko @ 2013-11-08 2:02 UTC (permalink / raw) To: Tivy, Robert; +Cc: meta-arago@arago-project.org, Ring, Chris On Fri, Nov 08, 2013 at 12:33:00AM +0000, Tivy, Robert wrote: > Please see my comments inline below... Thanks, Rob! inline... > > -----Original Message----- > > From: Nelson, Sam > > Sent: Thursday, November 07, 2013 3:50 AM > > To: Maupin, Chase; meta-arago@arago-project.org > > Cc: Ring, Chris; Tivy, Robert > > Subject: RE: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > > ... > > > > > > >+ > > > >+S = "${WORKDIR}/git" > > > >+ > > > >+inherit module > > > >+ > > > >+do_compile () { > > > >+ cd ${S} > > > >+ make -f lu.mak module_clean > > > >+ make -f lu.mak module > > > >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR} > > > >TOOLCHAIN_PREFIX=${CROSS_COMPILE} > > > > > > You should use the default do_compile in the module.bbclass I think. > > You > > > should be able to pass this with MAKE_TARGETS variable. > > [Sam] Probably Chris and Rob on the CC list can comment on this. This > > will need change of the module. > > Can you please explain the change needed? I'm not familiar with do_compile(). Please see my other reply in this thread - I have both do_compile() and do_install() shown there. But the change would be more than just the make targets - there are slightly different variables used by default... Anyway, I won't be insisting on this change, unless it is trivial for you to change. > > > >+} > > > >+ > > > >+do_install () { > > > >+ cd ${S} > > > >+ make -f lu.mak module_install > > > >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" > > > >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra" > > > >INSTALL_MOD_PATH="${D}" > > > > > > Hmmm. The default do_install for the module.bbclass uses > > > "modules_install" instead of "module_install". If you can get the > > lu.mak file > > > updated that would be ideal. If not then you should at least copy > > the base > > > function which unsets some variables. > > > > > [Sam] Probably Chris and Rob on the CC list can comment on this. This > > will need change of the module. > > This should be fine, I will make a change to lu.mak and commit to ludev.git. > > How about module_clean? Should that be changed to modules_clean? Well, modules_install comes from the kernel, as one of the standard make targets. There is no module(s)_clean there though, so it's up to you: $ make help Cleaning targets: clean - Remove most generated files but keep the config and enough build support to build external modules mrproper - Remove all generated files + config + various backup files distclean - mrproper + remove editor backup and patch files Configuration targets: config - Update current config utilising a line-oriented program nconfig - Update current config utilising a ncurses menu based program menuconfig - Update current config utilising a menu based program xconfig - Update current config utilising a QT based front-end gconfig - Update current config utilising a GTK based front-end oldconfig - Update current config utilising a provided .config as base localmodconfig - Update current config disabling modules not loaded localyesconfig - Update current config converting local mods to core silentoldconfig - Same as oldconfig, but quietly, additionally update deps defconfig - New config with default from ARCH supplied defconfig savedefconfig - Save current config as ./defconfig (minimal config) allnoconfig - New config where all options are answered with no allyesconfig - New config where all options are accepted with yes allmodconfig - New config selecting modules when possible alldefconfig - New config with all symbols set to default randconfig - New config with random answer to all options listnewconfig - List new options olddefconfig - Same as silentoldconfig but sets new symbols to their default value Other generic targets: all - Build all targets marked with [*] * vmlinux - Build the bare kernel * modules - Build all modules modules_install - Install all modules to INSTALL_MOD_PATH (default: /) firmware_install- Install all firmware to INSTALL_FW_PATH (default: $(INSTALL_MOD_PATH)/lib/firmware) dir/ - Build all files in dir and below dir/file.[oisS] - Build specified target only dir/file.lst - Build specified mixed source/assembly target only (requires a recent binutils and recent build (System.map)) dir/file.ko - Build module including final link modules_prepare - Set up for building external modules tags/TAGS - Generate tags file for editors cscope - Generate cscope index gtags - Generate GNU GLOBAL index kernelrelease - Output the release version string kernelversion - Output the version stored in Makefile image_name - Output the image name headers_install - Install sanitised kernel headers to INSTALL_HDR_PATH (default: /usr/src/linux-3.11.4/usr) Static analysers checkstack - Generate a list of stack hogs namespacecheck - Name space analysis on compiled kernel versioncheck - Sanity check on version.h usage includecheck - Check for duplicate included header files export_report - List the usages of all exported symbols headers_check - Sanity check on exported headers headerdep - Detect inclusion cycles in headers coccicheck - Check with Coccinelle. Kernel packaging: rpm-pkg - Build both source and binary RPM kernel packages binrpm-pkg - Build only the binary kernel package deb-pkg - Build the kernel as a deb package tar-pkg - Build the kernel as an uncompressed tarball targz-pkg - Build the kernel as a gzip compressed tarball tarbz2-pkg - Build the kernel as a bzip2 compressed tarball tarxz-pkg - Build the kernel as a xz compressed tarball perf-tar-src-pkg - Build perf-3.11.4.tar source tarball perf-targz-src-pkg - Build perf-3.11.4.tar.gz source tarball perf-tarbz2-src-pkg - Build perf-3.11.4.tar.bz2 source tarball perf-tarxz-src-pkg - Build perf-3.11.4.tar.xz source tarball Documentation targets: Linux kernel internal documentation in different formats: htmldocs - HTML pdfdocs - PDF psdocs - Postscript xmldocs - XML DocBook mandocs - man pages installmandocs - install man pages generated by mandocs cleandocs - clean all generated DocBook files Architecture specific targets (x86): * bzImage - Compressed kernel image (arch/x86/boot/bzImage) install - Install kernel using (your) ~/bin/installkernel or (distribution) /sbin/installkernel or install to $(INSTALL_PATH) and run lilo fdimage - Create 1.4MB boot floppy image (arch/x86/boot/fdimage) fdimage144 - Create 1.4MB boot floppy image (arch/x86/boot/fdimage) fdimage288 - Create 2.8MB boot floppy image (arch/x86/boot/fdimage) isoimage - Create a boot CD-ROM image (arch/x86/boot/image.iso) bzdisk/fdimage*/isoimage also accept: FDARGS="..." arguments for the booted kernel FDINITRD=file initrd for the booted kernel kvmconfig - Enable additional options for guest kernel support x86_64_defconfig - Build for x86_64 i386_defconfig - Build for i386 make V=0|1 [targets] 0 => quiet build (default), 1 => verbose build make V=2 [targets] 2 => give reason for rebuild of target make O=dir [targets] Locate all output files in "dir", including .config make C=1 [targets] Check all c source with $CHECK (sparse by default) make C=2 [targets] Force check of all c source with $CHECK make RECORDMCOUNT_WARN=1 [targets] Warn about ignored mcount sections make W=n [targets] Enable extra gcc checks, n=1,2,3 where 1: warnings which may be relevant and do not occur too often 2: warnings which occur quite often but may still be relevant 3: more obscure warnings, can most likely be ignored Multiple levels can be combined with W=12 or W=123 Execute "make" or "make all" to build all targets marked with [*] For further info see the ./README file > > > Is there perhaps a value to having the version in the package name > > instead of > > > using _git versions? Will all SDKs be in step with using the same > > version? > > > > > [Sam] Chris or Rob, can you comment on this. I am not sure of when the > > other verticals pick up CMEM. > > I need to let Chris comment on this. > > > _______________________________________________ > meta-arago mailing list > meta-arago@arago-project.org > http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-07 11:49 ` Nelson, Sam 2013-11-08 0:33 ` Tivy, Robert @ 2013-11-08 1:53 ` Denys Dmytriyenko 2013-11-08 2:00 ` Tivy, Robert ` (2 more replies) 1 sibling, 3 replies; 17+ messages in thread From: Denys Dmytriyenko @ 2013-11-08 1:53 UTC (permalink / raw) To: Nelson, Sam; +Cc: meta-arago@arago-project.org, Ring, Chris On Thu, Nov 07, 2013 at 11:49:42AM +0000, Nelson, Sam wrote: > > > > -----Original Message----- > > From: Maupin, Chase > > Sent: Thursday, November 07, 2013 2:35 AM > > To: Nelson, Sam; meta-arago@arago-project.org > > Subject: RE: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > > >-----Original Message----- > > >From: meta-arago-bounces@arago-project.org [mailto:meta-arago- > > >bounces@arago-project.org] On Behalf Of Nelson, Sam > > >Sent: Thursday, November 07, 2013 10:34 AM > > >To: meta-arago@arago-project.org; Nelson, Sam > > >Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > > > >- Cmem module is used for user space contiguous memory alloation > > > > > >Signed-off-by: Sam Nelson <sam.nelson@ti.com> > > >--- > > > recipes-bsp/cmem/cmem-mod_git.bb | 26 > > >++++++++++++++++++++++++++ > > > recipes-bsp/cmem/cmem.inc | 12 ++++++++++++ > > > recipes-bsp/cmem/cmem_git.bb | 16 ++++++++++++++++ > > > 3 files changed, 54 insertions(+) > > > create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb > > > create mode 100644 recipes-bsp/cmem/cmem.inc > > > create mode 100644 recipes-bsp/cmem/cmem_git.bb > > > > This patch should be submitted to meta-ti@yoctoproject.org which is the > > meta-ti mailing list. > [Sam] Ok. I will do that. > > > > > > > >diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes- > > >bsp/cmem/cmem-mod_git.bb > > >new file mode 100644 > > >index 0000000..c402b72 > > >--- /dev/null > > >+++ b/recipes-bsp/cmem/cmem-mod_git.bb > > >@@ -0,0 +1,26 @@ > > >+DESCRIPTION="Contiguous memory allocation kernel module for > > >contiguous memory allocation from userspace " > > >+ > > >+include cmem.inc > > >+ > > >+NAME="cmem" > > > > Not sure what the NAME variable is for > [Sam] I am not sure either. This is probably because of initial template > used for creation of the recipe. I can remove it if this really not needed. This is not a variable used by bitbake, so assigning it and not using later is rather redundant. > > >+# This package builds a kernel module, use kernel PR as base and > > >append a local > > >+PR = "${MACHINE_KERNEL_PR}" > > >+PR_append = "a" > > >+ > > >+PKG_${PN} = "kernel-module-${PN}" > > > > I think what you are trying to do here is already handled by the > > package.bbclass. I assume you are trying to set the package name to kernel- > > module-cmem-mod? > > > > This raises the question of whether you want this to be cmem-mod for the > > recipe and PN or if you want cmem for the module and cmem-xyz for the > > libraries. > > > [Sam] I guess the alternative you are suggesting is cmem for the module and > cmem-lib for the libraries. I am not seeing a compelling reason to change. You can keep cmem-mod as the name of the recipe. And even if you keep it as the name of the package (i.e. not set PKG_${PN} above), it will still work just fine. So, if your recipe is called cmem-mod, but PKG_${PN} = "kernel-module-${PN}" then the resulting package will be called kernel-module-cmem-mod.ipk If you don't set PKG_${PN}, then the package will be called cmem-mod.ipk, but there will be an empty package kernel-module-cmem-mod.ipk that automatically depend on cmem-mod.ipk :) At the end of the day, it will work just fine, as long as you don't mess the FILES_${PN} variable... > > >+S = "${WORKDIR}/git" > > >+ > > >+inherit module > > >+ > > >+do_compile () { > > >+ cd ${S} > > >+ make -f lu.mak module_clean > > >+ make -f lu.mak module > > >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR} > > >TOOLCHAIN_PREFIX=${CROSS_COMPILE} > > > > You should use the default do_compile in the module.bbclass I think. You > > should be able to pass this with MAKE_TARGETS variable. > > [Sam] Probably Chris and Rob on the CC list can comment on this. This will > need change of the module. Well, it is rather "nice to have" - I won't require this as a mandatory change. After all, components may come from different environments and it's unrealistic to demand them to come with a comformant Makefile... But, in case it would be possible and easy to change the Makefile, here's how default do_compile and do_install functions look like for a module: module_do_compile() { unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \ KERNEL_SRC=${STAGING_KERNEL_DIR} \ KERNEL_VERSION=${KERNEL_VERSION} \ CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ AR="${KERNEL_AR}" \ ${MAKE_TARGETS} } module_do_install() { unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \ KERNEL_SRC=${STAGING_KERNEL_DIR} \ CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ modules_install } You are only supposed to set MAKE_TARGETS variable, which in your case would be "module_clean module"... > > >+} > > >+ > > >+do_install () { > > >+ cd ${S} > > >+ make -f lu.mak module_install > > >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" > > >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra" > > >INSTALL_MOD_PATH="${D}" > > > > Hmmm. The default do_install for the module.bbclass uses > > "modules_install" instead of "module_install". If you can get the lu.mak file > > updated that would be ideal. If not then you should at least copy the base > > function which unsets some variables. > > > [Sam] Probably Chris and Rob on the CC list can comment on this. This will > need change of the module. Again, if changing the component is not really possible at this time, just unset all those *FLAGS variables above. > > >+} > > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc > > >new file mode 100644 > > >index 0000000..5d17d8e > > >--- /dev/null > > >+++ b/recipes-bsp/cmem/cmem.inc > > >@@ -0,0 +1,12 @@ > > >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM" > > >+ > > >+LICENSE = "GPLv2" > > >+LIC_FILES_CHKSUM = > > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb > > >8310b3b983024edc620" > > >+ > > >+COMPATIBLE_MACHINE = "keystone-evm" > > > > As Sidd pointed out is there any reason not to add the other devices like > > omap-a15 as compatible machines? > > [Sam] I am fine with remove the compatible machine. Although this is not > tested with other machines. So, Chris and Rob should comment on which platforms this version of cmem is supposed to be compatible with, even if it's not tested yet. > > >+BRANCH ?= "master" > > >+#SRCREV = "4.00.00.06" > > > > Remove this comment but add one that the commit id below corresponds to > > release 4.00.00.06. > > > [Sam] I will fix this. > > Is there perhaps a value to having the version in the package name instead of > > using _git versions? Will all SDKs be in step with using the same version? > > > [Sam] Chris or Rob, can you comment on this. I am not sure of when the > other verticals pick up CMEM. > > > >+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d" > > >+ > > >+SRC_URI = > > >"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}" > > >diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes- > > >bsp/cmem/cmem_git.bb > > >new file mode 100644 > > >index 0000000..f415630 > > >--- /dev/null > > >+++ b/recipes-bsp/cmem/cmem_git.bb > > >@@ -0,0 +1,16 @@ > > >+DESCRIPTION="The cmem component supports contiguous memory > > >allocation from userspace " > > >+ > > >+include cmem.inc > > >+ > > >+RDEPENDS_${PN} = "cmem-mod" > > >+ > > >+S = "${WORKDIR}/git" > > >+ > > >+PR = "r0" > > >+ > > >+PACKAGES =+ "${PN}-test" > > >+ > > >+FILES_${PN}-test = "${bindir}/*" > > > > As Denys pointed out last time, if everything goes into cmem-test then why > > not just call this whole recipe cmem-test since the base cmem package is > > empty. > > [Sam] The cmem package has the library that goes into cmem-dev. And hence > the name cmem. cmem-test will have the example/unit test code binaries. > Only thing is there is no binary files associated with the cmem package > itself. Right, we discussed some of this before and yesterday as well. It is not obvious, but a correct use case nevertheless. So, let's keep the name. But, now I have one question - you do mention a library that goes to cmem-dev. Is is a dynamic library? If so, it should rather go into the main package. I suspect it lacks the correect extension and hence ends up in the -dev package. > > >+inherit autotools > > >+ > > >-- > > >1.7.9.5 > > > > > >_______________________________________________ > > >meta-arago mailing list > > >meta-arago@arago-project.org > > >http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago > _______________________________________________ > meta-arago mailing list > meta-arago@arago-project.org > http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-08 1:53 ` Denys Dmytriyenko @ 2013-11-08 2:00 ` Tivy, Robert 2013-11-08 2:03 ` Denys Dmytriyenko 2013-11-08 2:06 ` Nelson, Sam 2013-11-12 21:01 ` Nelson, Sam 2 siblings, 1 reply; 17+ messages in thread From: Tivy, Robert @ 2013-11-08 2:00 UTC (permalink / raw) To: Dmytriyenko, Denys, Nelson, Sam; +Cc: meta-arago@arago-project.org, Ring, Chris Please see one response below... Regards, - Rob > -----Original Message----- > From: Dmytriyenko, Denys > Sent: Thursday, November 07, 2013 5:53 PM > To: Nelson, Sam > Cc: Maupin, Chase; meta-arago@arago-project.org; Ring, Chris; Tivy, > Robert > Subject: Re: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > > > >+} > > > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc > > > >new file mode 100644 > > > >index 0000000..5d17d8e > > > >--- /dev/null > > > >+++ b/recipes-bsp/cmem/cmem.inc > > > >@@ -0,0 +1,12 @@ > > > >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM" > > > >+ > > > >+LICENSE = "GPLv2" > > > >+LIC_FILES_CHKSUM = > > > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb > > > >8310b3b983024edc620" > > > >+ > > > >+COMPATIBLE_MACHINE = "keystone-evm" > > > > > > As Sidd pointed out is there any reason not to add the other > devices like > > > omap-a15 as compatible machines? > > > > [Sam] I am fine with remove the compatible machine. Although this is > not > > tested with other machines. > > So, Chris and Rob should comment on which platforms this version of > cmem is > supposed to be compatible with, even if it's not tested yet. > CMEM is completely architecture-independent. The only HW it touches is memory, and the memory it touches is specified by the user/system integrator. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-08 2:00 ` Tivy, Robert @ 2013-11-08 2:03 ` Denys Dmytriyenko 2013-11-08 2:04 ` Nelson, Sam 0 siblings, 1 reply; 17+ messages in thread From: Denys Dmytriyenko @ 2013-11-08 2:03 UTC (permalink / raw) To: Tivy, Robert; +Cc: meta-arago@arago-project.org, Ring, Chris On Thu, Nov 07, 2013 at 09:00:08PM -0500, Tivy, Robert wrote: > Please see one response below... > > Regards, > > - Rob > > > -----Original Message----- > > From: Dmytriyenko, Denys > > Sent: Thursday, November 07, 2013 5:53 PM > > To: Nelson, Sam > > Cc: Maupin, Chase; meta-arago@arago-project.org; Ring, Chris; Tivy, > > Robert > > Subject: Re: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > > > > > > >+} > > > > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc > > > > >new file mode 100644 > > > > >index 0000000..5d17d8e > > > > >--- /dev/null > > > > >+++ b/recipes-bsp/cmem/cmem.inc > > > > >@@ -0,0 +1,12 @@ > > > > >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM" > > > > >+ > > > > >+LICENSE = "GPLv2" > > > > >+LIC_FILES_CHKSUM = > > > > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb > > > > >8310b3b983024edc620" > > > > >+ > > > > >+COMPATIBLE_MACHINE = "keystone-evm" > > > > > > > > As Sidd pointed out is there any reason not to add the other > > devices like > > > > omap-a15 as compatible machines? > > > > > > [Sam] I am fine with remove the compatible machine. Although this is > > not > > > tested with other machines. > > > > So, Chris and Rob should comment on which platforms this version of > > cmem is > > supposed to be compatible with, even if it's not tested yet. > > > > CMEM is completely architecture-independent. The only HW it touches is > memory, and the memory it touches is specified by the user/system > integrator. Thanks. Then it doesn't make sense to artificially limit it to Keystone only. -- Denys ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-08 2:03 ` Denys Dmytriyenko @ 2013-11-08 2:04 ` Nelson, Sam 0 siblings, 0 replies; 17+ messages in thread From: Nelson, Sam @ 2013-11-08 2:04 UTC (permalink / raw) To: Dmytriyenko, Denys, Tivy, Robert Cc: meta-arago@arago-project.org, Ring, Chris > -----Original Message----- > From: Dmytriyenko, Denys > Sent: Thursday, November 07, 2013 9:04 PM > To: Tivy, Robert > Cc: Nelson, Sam; Maupin, Chase; meta-arago@arago-project.org; Ring, Chris > Subject: Re: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > On Thu, Nov 07, 2013 at 09:00:08PM -0500, Tivy, Robert wrote: > > Please see one response below... > > > > Regards, > > > > - Rob > > > > > -----Original Message----- > > > From: Dmytriyenko, Denys > > > Sent: Thursday, November 07, 2013 5:53 PM > > > To: Nelson, Sam > > > Cc: Maupin, Chase; meta-arago@arago-project.org; Ring, Chris; Tivy, > > > Robert > > > Subject: Re: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > > > > > > > > > >+} > > > > > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes- > bsp/cmem/cmem.inc > > > > > >new file mode 100644 > > > > > >index 0000000..5d17d8e > > > > > >--- /dev/null > > > > > >+++ b/recipes-bsp/cmem/cmem.inc > > > > > >@@ -0,0 +1,12 @@ > > > > > > >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM" > > > > > >+ > > > > > >+LICENSE = "GPLv2" > > > > > >+LIC_FILES_CHKSUM = > > > > > > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb > > > > > >8310b3b983024edc620" > > > > > >+ > > > > > >+COMPATIBLE_MACHINE = "keystone-evm" > > > > > > > > > > As Sidd pointed out is there any reason not to add the other > > > devices like > > > > > omap-a15 as compatible machines? > > > > > > > > [Sam] I am fine with remove the compatible machine. Although this is > > > not > > > > tested with other machines. > > > > > > So, Chris and Rob should comment on which platforms this version of > > > cmem is > > > supposed to be compatible with, even if it's not tested yet. > > > > > > > CMEM is completely architecture-independent. The only HW it touches is > > memory, and the memory it touches is specified by the user/system > > integrator. > > Thanks. Then it doesn't make sense to artificially limit it to Keystone only. [Sam] Agreed. I will remove COMPATIBLE_MACHINE = "keystone-evm" > > -- > Denys ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-08 1:53 ` Denys Dmytriyenko 2013-11-08 2:00 ` Tivy, Robert @ 2013-11-08 2:06 ` Nelson, Sam 2013-11-12 21:01 ` Nelson, Sam 2 siblings, 0 replies; 17+ messages in thread From: Nelson, Sam @ 2013-11-08 2:06 UTC (permalink / raw) To: Dmytriyenko, Denys; +Cc: meta-arago@arago-project.org, Ring, Chris > -----Original Message----- > From: Dmytriyenko, Denys > Sent: Thursday, November 07, 2013 8:53 PM > To: Nelson, Sam > Cc: Maupin, Chase; meta-arago@arago-project.org; Ring, Chris; Tivy, Robert > Subject: Re: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > On Thu, Nov 07, 2013 at 11:49:42AM +0000, Nelson, Sam wrote: > > > > > > > -----Original Message----- > > > From: Maupin, Chase > > > Sent: Thursday, November 07, 2013 2:35 AM > > > To: Nelson, Sam; meta-arago@arago-project.org > > > Subject: RE: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > > > > >-----Original Message----- > > > >From: meta-arago-bounces@arago-project.org [mailto:meta-arago- > > > >bounces@arago-project.org] On Behalf Of Nelson, Sam > > > >Sent: Thursday, November 07, 2013 10:34 AM > > > >To: meta-arago@arago-project.org; Nelson, Sam > > > >Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > > > > > >- Cmem module is used for user space contiguous memory alloation > > > > > > > >Signed-off-by: Sam Nelson <sam.nelson@ti.com> > > > >--- > > > > recipes-bsp/cmem/cmem-mod_git.bb | 26 > > > >++++++++++++++++++++++++++ > > > > recipes-bsp/cmem/cmem.inc | 12 ++++++++++++ > > > > recipes-bsp/cmem/cmem_git.bb | 16 ++++++++++++++++ > > > > 3 files changed, 54 insertions(+) > > > > create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb > > > > create mode 100644 recipes-bsp/cmem/cmem.inc > > > > create mode 100644 recipes-bsp/cmem/cmem_git.bb > > > > > > This patch should be submitted to meta-ti@yoctoproject.org which is the > > > meta-ti mailing list. > > [Sam] Ok. I will do that. > > > > > > > > > > >diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes- > > > >bsp/cmem/cmem-mod_git.bb > > > >new file mode 100644 > > > >index 0000000..c402b72 > > > >--- /dev/null > > > >+++ b/recipes-bsp/cmem/cmem-mod_git.bb > > > >@@ -0,0 +1,26 @@ > > > >+DESCRIPTION="Contiguous memory allocation kernel module for > > > >contiguous memory allocation from userspace " > > > >+ > > > >+include cmem.inc > > > >+ > > > >+NAME="cmem" > > > > > > Not sure what the NAME variable is for > > [Sam] I am not sure either. This is probably because of initial template > > used for creation of the recipe. I can remove it if this really not needed. > > This is not a variable used by bitbake, so assigning it and not using later is > rather redundant. > > > > > >+# This package builds a kernel module, use kernel PR as base and > > > >append a local > > > >+PR = "${MACHINE_KERNEL_PR}" > > > >+PR_append = "a" > > > >+ > > > >+PKG_${PN} = "kernel-module-${PN}" > > > > > > I think what you are trying to do here is already handled by the > > > package.bbclass. I assume you are trying to set the package name to > kernel- > > > module-cmem-mod? > > > > > > This raises the question of whether you want this to be cmem-mod for > the > > > recipe and PN or if you want cmem for the module and cmem-xyz for the > > > libraries. > > > > > [Sam] I guess the alternative you are suggesting is cmem for the module > and > > cmem-lib for the libraries. I am not seeing a compelling reason to change. > > You can keep cmem-mod as the name of the recipe. And even if you keep it > as the name of the package (i.e. not set PKG_${PN} above), it will still work > just fine. > > So, if your recipe is called cmem-mod, but PKG_${PN} = "kernel-module- > ${PN}" > then the resulting package will be called kernel-module-cmem-mod.ipk > > If you don't set PKG_${PN}, then the package will be called cmem-mod.ipk, > but > there will be an empty package kernel-module-cmem-mod.ipk that > automatically > depend on cmem-mod.ipk :) At the end of the day, it will work just fine, as > long as you don't mess the FILES_${PN} variable... > [Sam] I will remove the line PKG_${PN} = "kernel-module-${PN}" > > > > >+S = "${WORKDIR}/git" > > > >+ > > > >+inherit module > > > >+ > > > >+do_compile () { > > > >+ cd ${S} > > > >+ make -f lu.mak module_clean > > > >+ make -f lu.mak module > > > >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR} > > > >TOOLCHAIN_PREFIX=${CROSS_COMPILE} > > > > > > You should use the default do_compile in the module.bbclass I think. > You > > > should be able to pass this with MAKE_TARGETS variable. > > > > [Sam] Probably Chris and Rob on the CC list can comment on this. This will > > need change of the module. > > Well, it is rather "nice to have" - I won't require this as a mandatory > change. After all, components may come from different environments and > it's > unrealistic to demand them to come with a comformant Makefile... > > But, in case it would be possible and easy to change the Makefile, here's how > default do_compile and do_install functions look like for a module: > > module_do_compile() { > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \ > KERNEL_SRC=${STAGING_KERNEL_DIR} \ > KERNEL_VERSION=${KERNEL_VERSION} \ > CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ > AR="${KERNEL_AR}" \ > ${MAKE_TARGETS} > } > > module_do_install() { > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \ > KERNEL_SRC=${STAGING_KERNEL_DIR} \ > CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ > modules_install > } > > You are only supposed to set MAKE_TARGETS variable, which in your case > would > be "module_clean module"... > > > > > >+} > > > >+ > > > >+do_install () { > > > >+ cd ${S} > > > >+ make -f lu.mak module_install > > > >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" > > > >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra" > > > >INSTALL_MOD_PATH="${D}" > > > > > > Hmmm. The default do_install for the module.bbclass uses > > > "modules_install" instead of "module_install". If you can get the lu.mak > file > > > updated that would be ideal. If not then you should at least copy the > base > > > function which unsets some variables. > > > > > [Sam] Probably Chris and Rob on the CC list can comment on this. This will > > need change of the module. > > Again, if changing the component is not really possible at this time, just > unset all those *FLAGS variables above. > > > > > >+} > > > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc > > > >new file mode 100644 > > > >index 0000000..5d17d8e > > > >--- /dev/null > > > >+++ b/recipes-bsp/cmem/cmem.inc > > > >@@ -0,0 +1,12 @@ > > > > >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM" > > > >+ > > > >+LICENSE = "GPLv2" > > > >+LIC_FILES_CHKSUM = > > > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb > > > >8310b3b983024edc620" > > > >+ > > > >+COMPATIBLE_MACHINE = "keystone-evm" > > > > > > As Sidd pointed out is there any reason not to add the other devices like > > > omap-a15 as compatible machines? > > > > [Sam] I am fine with remove the compatible machine. Although this is not > > tested with other machines. > > So, Chris and Rob should comment on which platforms this version of cmem > is > supposed to be compatible with, even if it's not tested yet. > > > > > >+BRANCH ?= "master" > > > >+#SRCREV = "4.00.00.06" > > > > > > Remove this comment but add one that the commit id below corresponds > to > > > release 4.00.00.06. > > > > > [Sam] I will fix this. > > > Is there perhaps a value to having the version in the package name > instead of > > > using _git versions? Will all SDKs be in step with using the same version? > > > > > [Sam] Chris or Rob, can you comment on this. I am not sure of when the > > other verticals pick up CMEM. > > > > > >+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d" > > > >+ > > > >+SRC_URI = > > > >"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}" > > > >diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes- > > > >bsp/cmem/cmem_git.bb > > > >new file mode 100644 > > > >index 0000000..f415630 > > > >--- /dev/null > > > >+++ b/recipes-bsp/cmem/cmem_git.bb > > > >@@ -0,0 +1,16 @@ > > > >+DESCRIPTION="The cmem component supports contiguous memory > > > >allocation from userspace " > > > >+ > > > >+include cmem.inc > > > >+ > > > >+RDEPENDS_${PN} = "cmem-mod" > > > >+ > > > >+S = "${WORKDIR}/git" > > > >+ > > > >+PR = "r0" > > > >+ > > > >+PACKAGES =+ "${PN}-test" > > > >+ > > > >+FILES_${PN}-test = "${bindir}/*" > > > > > > As Denys pointed out last time, if everything goes into cmem-test then > why > > > not just call this whole recipe cmem-test since the base cmem package is > > > empty. > > > > [Sam] The cmem package has the library that goes into cmem-dev. And > hence > > the name cmem. cmem-test will have the example/unit test code binaries. > > Only thing is there is no binary files associated with the cmem package > > itself. > > Right, we discussed some of this before and yesterday as well. It is not > obvious, but a correct use case nevertheless. So, let's keep the name. > > But, now I have one question - you do mention a library that goes to cmem- > dev. > Is is a dynamic library? If so, it should rather go into the main package. I > suspect it lacks the correect extension and hence ends up in the -dev > package. > [Sam] There is both static and dynamic library here. Actually the shared library will be part of cmem package. ( The static library will be part of cmem-dev) > > > > >+inherit autotools > > > >+ > > > >-- > > > >1.7.9.5 > > > > > > > >_______________________________________________ > > > >meta-arago mailing list > > > >meta-arago@arago-project.org > > > >http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago > > _______________________________________________ > > meta-arago mailing list > > meta-arago@arago-project.org > > http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-08 1:53 ` Denys Dmytriyenko 2013-11-08 2:00 ` Tivy, Robert 2013-11-08 2:06 ` Nelson, Sam @ 2013-11-12 21:01 ` Nelson, Sam 2013-11-12 21:20 ` Denys Dmytriyenko 2 siblings, 1 reply; 17+ messages in thread From: Nelson, Sam @ 2013-11-12 21:01 UTC (permalink / raw) To: Dmytriyenko, Denys; +Cc: meta-arago@arago-project.org, Ring, Chris > -----Original Message----- > From: Dmytriyenko, Denys > Sent: Thursday, November 07, 2013 8:53 PM > To: Nelson, Sam > Cc: Maupin, Chase; meta-arago@arago-project.org; Ring, Chris; Tivy, Robert > Subject: Re: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > On Thu, Nov 07, 2013 at 11:49:42AM +0000, Nelson, Sam wrote: > > > > > > > -----Original Message----- > > > From: Maupin, Chase > > > Sent: Thursday, November 07, 2013 2:35 AM > > > To: Nelson, Sam; meta-arago@arago-project.org > > > Subject: RE: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > > > > >-----Original Message----- > > > >From: meta-arago-bounces@arago-project.org [mailto:meta-arago- > > > >bounces@arago-project.org] On Behalf Of Nelson, Sam > > > >Sent: Thursday, November 07, 2013 10:34 AM > > > >To: meta-arago@arago-project.org; Nelson, Sam > > > >Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > > > > > >- Cmem module is used for user space contiguous memory alloation > > > > > > > >Signed-off-by: Sam Nelson <sam.nelson@ti.com> > > > >--- > > > > recipes-bsp/cmem/cmem-mod_git.bb | 26 > > > >++++++++++++++++++++++++++ > > > > recipes-bsp/cmem/cmem.inc | 12 ++++++++++++ > > > > recipes-bsp/cmem/cmem_git.bb | 16 ++++++++++++++++ > > > > 3 files changed, 54 insertions(+) > > > > create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb > > > > create mode 100644 recipes-bsp/cmem/cmem.inc > > > > create mode 100644 recipes-bsp/cmem/cmem_git.bb > > > > > > This patch should be submitted to meta-ti@yoctoproject.org which is the > > > meta-ti mailing list. > > [Sam] Ok. I will do that. > > > > > > > > > > >diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes- > > > >bsp/cmem/cmem-mod_git.bb > > > >new file mode 100644 > > > >index 0000000..c402b72 > > > >--- /dev/null > > > >+++ b/recipes-bsp/cmem/cmem-mod_git.bb > > > >@@ -0,0 +1,26 @@ > > > >+DESCRIPTION="Contiguous memory allocation kernel module for > > > >contiguous memory allocation from userspace " > > > >+ > > > >+include cmem.inc > > > >+ > > > >+NAME="cmem" > > > > > > Not sure what the NAME variable is for > > [Sam] I am not sure either. This is probably because of initial template > > used for creation of the recipe. I can remove it if this really not needed. > > This is not a variable used by bitbake, so assigning it and not using later is > rather redundant. > > > > > >+# This package builds a kernel module, use kernel PR as base and > > > >append a local > > > >+PR = "${MACHINE_KERNEL_PR}" > > > >+PR_append = "a" > > > >+ > > > >+PKG_${PN} = "kernel-module-${PN}" > > > > > > I think what you are trying to do here is already handled by the > > > package.bbclass. I assume you are trying to set the package name to > kernel- > > > module-cmem-mod? > > > > > > This raises the question of whether you want this to be cmem-mod for > the > > > recipe and PN or if you want cmem for the module and cmem-xyz for the > > > libraries. > > > > > [Sam] I guess the alternative you are suggesting is cmem for the module > and > > cmem-lib for the libraries. I am not seeing a compelling reason to change. > > You can keep cmem-mod as the name of the recipe. And even if you keep it > as the name of the package (i.e. not set PKG_${PN} above), it will still work > just fine. > > So, if your recipe is called cmem-mod, but PKG_${PN} = "kernel-module- > ${PN}" > then the resulting package will be called kernel-module-cmem-mod.ipk > > If you don't set PKG_${PN}, then the package will be called cmem-mod.ipk, > but > there will be an empty package kernel-module-cmem-mod.ipk that > automatically > depend on cmem-mod.ipk :) At the end of the day, it will work just fine, as > long as you don't mess the FILES_${PN} variable... > > > > > >+S = "${WORKDIR}/git" > > > >+ > > > >+inherit module > > > >+ > > > >+do_compile () { > > > >+ cd ${S} > > > >+ make -f lu.mak module_clean > > > >+ make -f lu.mak module > > > >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR} > > > >TOOLCHAIN_PREFIX=${CROSS_COMPILE} > > > > > > You should use the default do_compile in the module.bbclass I think. > You > > > should be able to pass this with MAKE_TARGETS variable. > > > > [Sam] Probably Chris and Rob on the CC list can comment on this. This will > > need change of the module. > > Well, it is rather "nice to have" - I won't require this as a mandatory > change. After all, components may come from different environments and > it's > unrealistic to demand them to come with a comformant Makefile... > > But, in case it would be possible and easy to change the Makefile, here's how > default do_compile and do_install functions look like for a module: > > module_do_compile() { > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \ > KERNEL_SRC=${STAGING_KERNEL_DIR} \ > KERNEL_VERSION=${KERNEL_VERSION} \ > CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ > AR="${KERNEL_AR}" \ > ${MAKE_TARGETS} > } > > module_do_install() { > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \ > KERNEL_SRC=${STAGING_KERNEL_DIR} \ > CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ > modules_install > } > > You are only supposed to set MAKE_TARGETS variable, which in your case > would > be "module_clean module"... [Sam] we will add the unset FLAGS. Am I supposed to also rename do_install to module_do_install, do_compile --> module_do_install. And also will add module_do_clean? Please confirm. Currently we have to still use non-standard makefile. > > > > > >+} > > > >+ > > > >+do_install () { > > > >+ cd ${S} > > > >+ make -f lu.mak module_install > > > >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" > > > >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra" > > > >INSTALL_MOD_PATH="${D}" > > > > > > Hmmm. The default do_install for the module.bbclass uses > > > "modules_install" instead of "module_install". If you can get the lu.mak > file > > > updated that would be ideal. If not then you should at least copy the > base > > > function which unsets some variables. > > > > > [Sam] Probably Chris and Rob on the CC list can comment on this. This will > > need change of the module. > > Again, if changing the component is not really possible at this time, just > unset all those *FLAGS variables above. > > > > > >+} > > > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc > > > >new file mode 100644 > > > >index 0000000..5d17d8e > > > >--- /dev/null > > > >+++ b/recipes-bsp/cmem/cmem.inc > > > >@@ -0,0 +1,12 @@ > > > > >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM" > > > >+ > > > >+LICENSE = "GPLv2" > > > >+LIC_FILES_CHKSUM = > > > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb > > > >8310b3b983024edc620" > > > >+ > > > >+COMPATIBLE_MACHINE = "keystone-evm" > > > > > > As Sidd pointed out is there any reason not to add the other devices like > > > omap-a15 as compatible machines? > > > > [Sam] I am fine with remove the compatible machine. Although this is not > > tested with other machines. > > So, Chris and Rob should comment on which platforms this version of cmem > is > supposed to be compatible with, even if it's not tested yet. > > > > > >+BRANCH ?= "master" > > > >+#SRCREV = "4.00.00.06" > > > > > > Remove this comment but add one that the commit id below corresponds > to > > > release 4.00.00.06. > > > > > [Sam] I will fix this. > > > Is there perhaps a value to having the version in the package name > instead of > > > using _git versions? Will all SDKs be in step with using the same version? > > > > > [Sam] Chris or Rob, can you comment on this. I am not sure of when the > > other verticals pick up CMEM. > > > > > >+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d" > > > >+ > > > >+SRC_URI = > > > >"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}" > > > >diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes- > > > >bsp/cmem/cmem_git.bb > > > >new file mode 100644 > > > >index 0000000..f415630 > > > >--- /dev/null > > > >+++ b/recipes-bsp/cmem/cmem_git.bb > > > >@@ -0,0 +1,16 @@ > > > >+DESCRIPTION="The cmem component supports contiguous memory > > > >allocation from userspace " > > > >+ > > > >+include cmem.inc > > > >+ > > > >+RDEPENDS_${PN} = "cmem-mod" > > > >+ > > > >+S = "${WORKDIR}/git" > > > >+ > > > >+PR = "r0" > > > >+ > > > >+PACKAGES =+ "${PN}-test" > > > >+ > > > >+FILES_${PN}-test = "${bindir}/*" > > > > > > As Denys pointed out last time, if everything goes into cmem-test then > why > > > not just call this whole recipe cmem-test since the base cmem package is > > > empty. > > > > [Sam] The cmem package has the library that goes into cmem-dev. And > hence > > the name cmem. cmem-test will have the example/unit test code binaries. > > Only thing is there is no binary files associated with the cmem package > > itself. > > Right, we discussed some of this before and yesterday as well. It is not > obvious, but a correct use case nevertheless. So, let's keep the name. > > But, now I have one question - you do mention a library that goes to cmem- > dev. > Is is a dynamic library? If so, it should rather go into the main package. I > suspect it lacks the correect extension and hence ends up in the -dev > package. > > > > > >+inherit autotools > > > >+ > > > >-- > > > >1.7.9.5 > > > > > > > >_______________________________________________ > > > >meta-arago mailing list > > > >meta-arago@arago-project.org > > > >http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago > > _______________________________________________ > > meta-arago mailing list > > meta-arago@arago-project.org > > http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-12 21:01 ` Nelson, Sam @ 2013-11-12 21:20 ` Denys Dmytriyenko 0 siblings, 0 replies; 17+ messages in thread From: Denys Dmytriyenko @ 2013-11-12 21:20 UTC (permalink / raw) To: Nelson, Sam; +Cc: meta-arago@arago-project.org, Ring, Chris On Tue, Nov 12, 2013 at 04:01:14PM -0500, Nelson, Sam wrote: > > > > -----Original Message----- > > From: Dmytriyenko, Denys > > Sent: Thursday, November 07, 2013 8:53 PM > > To: Nelson, Sam > > Cc: Maupin, Chase; meta-arago@arago-project.org; Ring, Chris; Tivy, Robert > > Subject: Re: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > > On Thu, Nov 07, 2013 at 11:49:42AM +0000, Nelson, Sam wrote: > > > > > > > > > > -----Original Message----- > > > > From: Maupin, Chase > > > > Sent: Thursday, November 07, 2013 2:35 AM > > > > To: Nelson, Sam; meta-arago@arago-project.org > > > > Subject: RE: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > > > > > > >-----Original Message----- > > > > >From: meta-arago-bounces@arago-project.org [mailto:meta-arago- > > > > >bounces@arago-project.org] On Behalf Of Nelson, Sam > > > > >Sent: Thursday, November 07, 2013 10:34 AM > > > > >To: meta-arago@arago-project.org; Nelson, Sam > > > > >Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > > > > > > > >- Cmem module is used for user space contiguous memory alloation > > > > > > > > > >Signed-off-by: Sam Nelson <sam.nelson@ti.com> > > > > >--- > > > > > recipes-bsp/cmem/cmem-mod_git.bb | 26 > > > > >++++++++++++++++++++++++++ > > > > > recipes-bsp/cmem/cmem.inc | 12 ++++++++++++ > > > > > recipes-bsp/cmem/cmem_git.bb | 16 ++++++++++++++++ > > > > > 3 files changed, 54 insertions(+) > > > > > create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb > > > > > create mode 100644 recipes-bsp/cmem/cmem.inc > > > > > create mode 100644 recipes-bsp/cmem/cmem_git.bb > > > > > > > > This patch should be submitted to meta-ti@yoctoproject.org which is the > > > > meta-ti mailing list. > > > [Sam] Ok. I will do that. > > > > > > > > > > > > > >diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes- > > > > >bsp/cmem/cmem-mod_git.bb > > > > >new file mode 100644 > > > > >index 0000000..c402b72 > > > > >--- /dev/null > > > > >+++ b/recipes-bsp/cmem/cmem-mod_git.bb > > > > >@@ -0,0 +1,26 @@ > > > > >+DESCRIPTION="Contiguous memory allocation kernel module for > > > > >contiguous memory allocation from userspace " > > > > >+ > > > > >+include cmem.inc > > > > >+ > > > > >+NAME="cmem" > > > > > > > > Not sure what the NAME variable is for > > > [Sam] I am not sure either. This is probably because of initial template > > > used for creation of the recipe. I can remove it if this really not needed. > > > > This is not a variable used by bitbake, so assigning it and not using later is > > rather redundant. > > > > > > > > >+# This package builds a kernel module, use kernel PR as base and > > > > >append a local > > > > >+PR = "${MACHINE_KERNEL_PR}" > > > > >+PR_append = "a" > > > > >+ > > > > >+PKG_${PN} = "kernel-module-${PN}" > > > > > > > > I think what you are trying to do here is already handled by the > > > > package.bbclass. I assume you are trying to set the package name to > > kernel- > > > > module-cmem-mod? > > > > > > > > This raises the question of whether you want this to be cmem-mod for > > the > > > > recipe and PN or if you want cmem for the module and cmem-xyz for the > > > > libraries. > > > > > > > [Sam] I guess the alternative you are suggesting is cmem for the module > > and > > > cmem-lib for the libraries. I am not seeing a compelling reason to change. > > > > You can keep cmem-mod as the name of the recipe. And even if you keep it > > as the name of the package (i.e. not set PKG_${PN} above), it will still work > > just fine. > > > > So, if your recipe is called cmem-mod, but PKG_${PN} = "kernel-module- > > ${PN}" > > then the resulting package will be called kernel-module-cmem-mod.ipk > > > > If you don't set PKG_${PN}, then the package will be called cmem-mod.ipk, > > but > > there will be an empty package kernel-module-cmem-mod.ipk that > > automatically > > depend on cmem-mod.ipk :) At the end of the day, it will work just fine, as > > long as you don't mess the FILES_${PN} variable... > > > > > > > > >+S = "${WORKDIR}/git" > > > > >+ > > > > >+inherit module > > > > >+ > > > > >+do_compile () { > > > > >+ cd ${S} > > > > >+ make -f lu.mak module_clean > > > > >+ make -f lu.mak module > > > > >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR} > > > > >TOOLCHAIN_PREFIX=${CROSS_COMPILE} > > > > > > > > You should use the default do_compile in the module.bbclass I think. > > You > > > > should be able to pass this with MAKE_TARGETS variable. > > > > > > [Sam] Probably Chris and Rob on the CC list can comment on this. This will > > > need change of the module. > > > > Well, it is rather "nice to have" - I won't require this as a mandatory > > change. After all, components may come from different environments and > > it's > > unrealistic to demand them to come with a comformant Makefile... > > > > But, in case it would be possible and easy to change the Makefile, here's how > > default do_compile and do_install functions look like for a module: > > > > module_do_compile() { > > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > > oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \ > > KERNEL_SRC=${STAGING_KERNEL_DIR} \ > > KERNEL_VERSION=${KERNEL_VERSION} \ > > CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ > > AR="${KERNEL_AR}" \ > > ${MAKE_TARGETS} > > } > > > > module_do_install() { > > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > > oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \ > > KERNEL_SRC=${STAGING_KERNEL_DIR} \ > > CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ > > modules_install > > } > > > > You are only supposed to set MAKE_TARGETS variable, which in your case > > would > > be "module_clean module"... > [Sam] we will add the unset FLAGS. Am I supposed to also rename do_install > to module_do_install, do_compile --> module_do_install. And also will add > module_do_clean? Please confirm. Currently we have to still use non-standard > makefile. No, providing own do_install and do_compile should be fine for now, if you can't change module's Makefile. > > > > >+} > > > > >+ > > > > >+do_install () { > > > > >+ cd ${S} > > > > >+ make -f lu.mak module_install > > > > >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" > > > > >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra" > > > > >INSTALL_MOD_PATH="${D}" > > > > > > > > Hmmm. The default do_install for the module.bbclass uses > > > > "modules_install" instead of "module_install". If you can get the lu.mak > > file > > > > updated that would be ideal. If not then you should at least copy the > > base > > > > function which unsets some variables. > > > > > > > [Sam] Probably Chris and Rob on the CC list can comment on this. This will > > > need change of the module. > > > > Again, if changing the component is not really possible at this time, just > > unset all those *FLAGS variables above. > > > > > > > > >+} > > > > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc > > > > >new file mode 100644 > > > > >index 0000000..5d17d8e > > > > >--- /dev/null > > > > >+++ b/recipes-bsp/cmem/cmem.inc > > > > >@@ -0,0 +1,12 @@ > > > > > > >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM" > > > > >+ > > > > >+LICENSE = "GPLv2" > > > > >+LIC_FILES_CHKSUM = > > > > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb > > > > >8310b3b983024edc620" > > > > >+ > > > > >+COMPATIBLE_MACHINE = "keystone-evm" > > > > > > > > As Sidd pointed out is there any reason not to add the other devices like > > > > omap-a15 as compatible machines? > > > > > > [Sam] I am fine with remove the compatible machine. Although this is not > > > tested with other machines. > > > > So, Chris and Rob should comment on which platforms this version of cmem > > is > > supposed to be compatible with, even if it's not tested yet. > > > > > > > > >+BRANCH ?= "master" > > > > >+#SRCREV = "4.00.00.06" > > > > > > > > Remove this comment but add one that the commit id below corresponds > > to > > > > release 4.00.00.06. > > > > > > > [Sam] I will fix this. > > > > Is there perhaps a value to having the version in the package name > > instead of > > > > using _git versions? Will all SDKs be in step with using the same version? > > > > > > > [Sam] Chris or Rob, can you comment on this. I am not sure of when the > > > other verticals pick up CMEM. > > > > > > > >+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d" > > > > >+ > > > > >+SRC_URI = > > > > >"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}" > > > > >diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes- > > > > >bsp/cmem/cmem_git.bb > > > > >new file mode 100644 > > > > >index 0000000..f415630 > > > > >--- /dev/null > > > > >+++ b/recipes-bsp/cmem/cmem_git.bb > > > > >@@ -0,0 +1,16 @@ > > > > >+DESCRIPTION="The cmem component supports contiguous memory > > > > >allocation from userspace " > > > > >+ > > > > >+include cmem.inc > > > > >+ > > > > >+RDEPENDS_${PN} = "cmem-mod" > > > > >+ > > > > >+S = "${WORKDIR}/git" > > > > >+ > > > > >+PR = "r0" > > > > >+ > > > > >+PACKAGES =+ "${PN}-test" > > > > >+ > > > > >+FILES_${PN}-test = "${bindir}/*" > > > > > > > > As Denys pointed out last time, if everything goes into cmem-test then > > why > > > > not just call this whole recipe cmem-test since the base cmem package is > > > > empty. > > > > > > [Sam] The cmem package has the library that goes into cmem-dev. And > > hence > > > the name cmem. cmem-test will have the example/unit test code binaries. > > > Only thing is there is no binary files associated with the cmem package > > > itself. > > > > Right, we discussed some of this before and yesterday as well. It is not > > obvious, but a correct use case nevertheless. So, let's keep the name. > > > > But, now I have one question - you do mention a library that goes to cmem- > > dev. > > Is is a dynamic library? If so, it should rather go into the main package. I > > suspect it lacks the correect extension and hence ends up in the -dev > > package. > > > > > > > > >+inherit autotools > > > > >+ > > > > >-- > > > > >1.7.9.5 > > > > > > > > > >_______________________________________________ > > > > >meta-arago mailing list > > > > >meta-arago@arago-project.org > > > > >http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago > > > _______________________________________________ > > > meta-arago mailing list > > > meta-arago@arago-project.org > > > http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-07 5:03 [PATCH v2] cmem: Adding New recipe for cmem Sam Nelson 2013-11-07 7:35 ` Maupin, Chase @ 2013-11-20 13:11 ` Maupin, Chase 2013-11-20 15:24 ` Denys Dmytriyenko 1 sibling, 1 reply; 17+ messages in thread From: Maupin, Chase @ 2013-11-20 13:11 UTC (permalink / raw) To: Nelson, Sam, meta-arago@arago-project.org Sam, Were you going to post an updated set of these patches to meta-ti so you can align with Mrinmayee? I think your approach of splitting out the packages in linux-utils is a good one and will be cleaner going forward. Since both of your groups share these packages aligning between the two would be helpful. As a side note I assume you have other recipes that depend on the cmem libraries that your cmem recipe provides. Can you post one of those or share it with Mrinmayee as an example of how you are able to point to the right staging location for the libraries and headers for cmem in other recipes. I'm hoping we can start getting rid of ti-paths.inc but I'd like to see how you were working around this. Denys, Since ti-linuxutils has other modules in it for edma, sdma, and irq but those are only for legacy devices can we just replace the whole ti-linuxutils with the cmem package which seems to be the main package needed? Or do you want to see additional recipes for the sdma, edma, and irq moduled? >-----Original Message----- >From: meta-arago-bounces@arago-project.org [mailto:meta-arago- >bounces@arago-project.org] On Behalf Of Nelson, Sam >Sent: Wednesday, November 06, 2013 11:04 PM >To: meta-arago@arago-project.org; Nelson, Sam >Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > >- Cmem module is used for user space contiguous memory alloation > >Signed-off-by: Sam Nelson <sam.nelson@ti.com> >--- > recipes-bsp/cmem/cmem-mod_git.bb | 26 >++++++++++++++++++++++++++ > recipes-bsp/cmem/cmem.inc | 12 ++++++++++++ > recipes-bsp/cmem/cmem_git.bb | 16 ++++++++++++++++ > 3 files changed, 54 insertions(+) > create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb > create mode 100644 recipes-bsp/cmem/cmem.inc > create mode 100644 recipes-bsp/cmem/cmem_git.bb > >diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes- >bsp/cmem/cmem-mod_git.bb >new file mode 100644 >index 0000000..c402b72 >--- /dev/null >+++ b/recipes-bsp/cmem/cmem-mod_git.bb >@@ -0,0 +1,26 @@ >+DESCRIPTION="Contiguous memory allocation kernel module for >contiguous memory allocation from userspace " >+ >+include cmem.inc >+ >+NAME="cmem" >+ >+# This package builds a kernel module, use kernel PR as base and >append a local >+PR = "${MACHINE_KERNEL_PR}" >+PR_append = "a" >+ >+PKG_${PN} = "kernel-module-${PN}" >+ >+S = "${WORKDIR}/git" >+ >+inherit module >+ >+do_compile () { >+ cd ${S} >+ make -f lu.mak module_clean >+ make -f lu.mak module >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR} >TOOLCHAIN_PREFIX=${CROSS_COMPILE} >+} >+ >+do_install () { >+ cd ${S} >+ make -f lu.mak module_install >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra" >INSTALL_MOD_PATH="${D}" >+} >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc >new file mode 100644 >index 0000000..5d17d8e >--- /dev/null >+++ b/recipes-bsp/cmem/cmem.inc >@@ -0,0 +1,12 @@ >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM" >+ >+LICENSE = "GPLv2" >+LIC_FILES_CHKSUM = >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb >8310b3b983024edc620" >+ >+COMPATIBLE_MACHINE = "keystone-evm" >+ >+BRANCH ?= "master" >+#SRCREV = "4.00.00.06" >+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d" >+ >+SRC_URI = >"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}" >diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes- >bsp/cmem/cmem_git.bb >new file mode 100644 >index 0000000..f415630 >--- /dev/null >+++ b/recipes-bsp/cmem/cmem_git.bb >@@ -0,0 +1,16 @@ >+DESCRIPTION="The cmem component supports contiguous memory >allocation from userspace " >+ >+include cmem.inc >+ >+RDEPENDS_${PN} = "cmem-mod" >+ >+S = "${WORKDIR}/git" >+ >+PR = "r0" >+ >+PACKAGES =+ "${PN}-test" >+ >+FILES_${PN}-test = "${bindir}/*" >+ >+inherit autotools >+ >-- >1.7.9.5 > >_______________________________________________ >meta-arago mailing list >meta-arago@arago-project.org >http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-20 13:11 ` Maupin, Chase @ 2013-11-20 15:24 ` Denys Dmytriyenko 2013-11-26 12:56 ` Enrico 0 siblings, 1 reply; 17+ messages in thread From: Denys Dmytriyenko @ 2013-11-20 15:24 UTC (permalink / raw) To: Maupin, Chase; +Cc: meta-arago@arago-project.org On Wed, Nov 20, 2013 at 01:11:18PM +0000, Maupin, Chase wrote: > Sam, > > Were you going to post an updated set of these patches to meta-ti so you can > align with Mrinmayee? I think your approach of splitting out the packages in > linux-utils is a good one and will be cleaner going forward. Since both of > your groups share these packages aligning between the two would be helpful. > > As a side note I assume you have other recipes that depend on the cmem > libraries that your cmem recipe provides. Can you post one of those or > share it with Mrinmayee as an example of how you are able to point to the > right staging location for the libraries and headers for cmem in other > recipes. I'm hoping we can start getting rid of ti-paths.inc but I'd like > to see how you were working around this. > > Denys, > > Since ti-linuxutils has other modules in it for edma, sdma, and irq but > those are only for legacy devices can we just replace the whole > ti-linuxutils with the cmem package which seems to be the main package > needed? Or do you want to see additional recipes for the sdma, edma, and > irq moduled? I'd like to see other parts of linuxutils modularized, but that can be done on as needed basis for any of the new platforms when they require those. We can keep the old linuxutils around for a little longer, but it can only be used on the old 35x and 37x plaftorms only and there are many other components (like SGX) removing support for those old platforms already... -- Denys > >-----Original Message----- > >From: meta-arago-bounces@arago-project.org [mailto:meta-arago- > >bounces@arago-project.org] On Behalf Of Nelson, Sam > >Sent: Wednesday, November 06, 2013 11:04 PM > >To: meta-arago@arago-project.org; Nelson, Sam > >Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem > > > >- Cmem module is used for user space contiguous memory alloation > > > >Signed-off-by: Sam Nelson <sam.nelson@ti.com> > >--- > > recipes-bsp/cmem/cmem-mod_git.bb | 26 > >++++++++++++++++++++++++++ > > recipes-bsp/cmem/cmem.inc | 12 ++++++++++++ > > recipes-bsp/cmem/cmem_git.bb | 16 ++++++++++++++++ > > 3 files changed, 54 insertions(+) > > create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb > > create mode 100644 recipes-bsp/cmem/cmem.inc > > create mode 100644 recipes-bsp/cmem/cmem_git.bb > > > >diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes- > >bsp/cmem/cmem-mod_git.bb > >new file mode 100644 > >index 0000000..c402b72 > >--- /dev/null > >+++ b/recipes-bsp/cmem/cmem-mod_git.bb > >@@ -0,0 +1,26 @@ > >+DESCRIPTION="Contiguous memory allocation kernel module for > >contiguous memory allocation from userspace " > >+ > >+include cmem.inc > >+ > >+NAME="cmem" > >+ > >+# This package builds a kernel module, use kernel PR as base and > >append a local > >+PR = "${MACHINE_KERNEL_PR}" > >+PR_append = "a" > >+ > >+PKG_${PN} = "kernel-module-${PN}" > >+ > >+S = "${WORKDIR}/git" > >+ > >+inherit module > >+ > >+do_compile () { > >+ cd ${S} > >+ make -f lu.mak module_clean > >+ make -f lu.mak module > >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR} > >TOOLCHAIN_PREFIX=${CROSS_COMPILE} > >+} > >+ > >+do_install () { > >+ cd ${S} > >+ make -f lu.mak module_install > >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" > >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra" > >INSTALL_MOD_PATH="${D}" > >+} > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc > >new file mode 100644 > >index 0000000..5d17d8e > >--- /dev/null > >+++ b/recipes-bsp/cmem/cmem.inc > >@@ -0,0 +1,12 @@ > >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM" > >+ > >+LICENSE = "GPLv2" > >+LIC_FILES_CHKSUM = > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb > >8310b3b983024edc620" > >+ > >+COMPATIBLE_MACHINE = "keystone-evm" > >+ > >+BRANCH ?= "master" > >+#SRCREV = "4.00.00.06" > >+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d" > >+ > >+SRC_URI = > >"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}" > >diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes- > >bsp/cmem/cmem_git.bb > >new file mode 100644 > >index 0000000..f415630 > >--- /dev/null > >+++ b/recipes-bsp/cmem/cmem_git.bb > >@@ -0,0 +1,16 @@ > >+DESCRIPTION="The cmem component supports contiguous memory > >allocation from userspace " > >+ > >+include cmem.inc > >+ > >+RDEPENDS_${PN} = "cmem-mod" > >+ > >+S = "${WORKDIR}/git" > >+ > >+PR = "r0" > >+ > >+PACKAGES =+ "${PN}-test" > >+ > >+FILES_${PN}-test = "${bindir}/*" > >+ > >+inherit autotools > >+ > >-- > >1.7.9.5 > > > >_______________________________________________ > >meta-arago mailing list > >meta-arago@arago-project.org > >http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago > _______________________________________________ > meta-arago mailing list > meta-arago@arago-project.org > http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-20 15:24 ` Denys Dmytriyenko @ 2013-11-26 12:56 ` Enrico 2013-11-27 16:55 ` Denys Dmytriyenko 0 siblings, 1 reply; 17+ messages in thread From: Enrico @ 2013-11-26 12:56 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: meta-arago@arago-project.org On Wed, Nov 20, 2013 at 4:24 PM, Denys Dmytriyenko <denys@ti.com> wrote: > On Wed, Nov 20, 2013 at 01:11:18PM +0000, Maupin, Chase wrote: >> Sam, >> >> Were you going to post an updated set of these patches to meta-ti so you can >> align with Mrinmayee? I think your approach of splitting out the packages in >> linux-utils is a good one and will be cleaner going forward. Since both of >> your groups share these packages aligning between the two would be helpful. >> >> As a side note I assume you have other recipes that depend on the cmem >> libraries that your cmem recipe provides. Can you post one of those or >> share it with Mrinmayee as an example of how you are able to point to the >> right staging location for the libraries and headers for cmem in other >> recipes. I'm hoping we can start getting rid of ti-paths.inc but I'd like >> to see how you were working around this. >> >> Denys, >> >> Since ti-linuxutils has other modules in it for edma, sdma, and irq but >> those are only for legacy devices can we just replace the whole >> ti-linuxutils with the cmem package which seems to be the main package >> needed? Or do you want to see additional recipes for the sdma, edma, and >> irq moduled? > > I'd like to see other parts of linuxutils modularized, but that can be done on > as needed basis for any of the new platforms when they require those. We can > keep the old linuxutils around for a little longer, but it can only be used on > the old 35x and 37x plaftorms only and there are many other components (like > SGX) removing support for those old platforms already... Please keep the linuxutils recipe until it can be replaced with the modularized ones, it's useful for 35x and 37x dsp (gstreamer_ti). Enrico ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-26 12:56 ` Enrico @ 2013-11-27 16:55 ` Denys Dmytriyenko 2013-11-28 8:20 ` Enrico 0 siblings, 1 reply; 17+ messages in thread From: Denys Dmytriyenko @ 2013-11-27 16:55 UTC (permalink / raw) To: Enrico; +Cc: meta-arago@arago-project.org On Tue, Nov 26, 2013 at 01:56:56PM +0100, Enrico wrote: > On Wed, Nov 20, 2013 at 4:24 PM, Denys Dmytriyenko <denys@ti.com> wrote: > > On Wed, Nov 20, 2013 at 01:11:18PM +0000, Maupin, Chase wrote: > >> Sam, > >> > >> Were you going to post an updated set of these patches to meta-ti so you can > >> align with Mrinmayee? I think your approach of splitting out the packages in > >> linux-utils is a good one and will be cleaner going forward. Since both of > >> your groups share these packages aligning between the two would be helpful. > >> > >> As a side note I assume you have other recipes that depend on the cmem > >> libraries that your cmem recipe provides. Can you post one of those or > >> share it with Mrinmayee as an example of how you are able to point to the > >> right staging location for the libraries and headers for cmem in other > >> recipes. I'm hoping we can start getting rid of ti-paths.inc but I'd like > >> to see how you were working around this. > >> > >> Denys, > >> > >> Since ti-linuxutils has other modules in it for edma, sdma, and irq but > >> those are only for legacy devices can we just replace the whole > >> ti-linuxutils with the cmem package which seems to be the main package > >> needed? Or do you want to see additional recipes for the sdma, edma, and > >> irq moduled? > > > > I'd like to see other parts of linuxutils modularized, but that can be done on > > as needed basis for any of the new platforms when they require those. We can > > keep the old linuxutils around for a little longer, but it can only be used on > > the old 35x and 37x plaftorms only and there are many other components (like > > SGX) removing support for those old platforms already... > > Please keep the linuxutils recipe until it can be replaced with the > modularized ones, it's useful for 35x and 37x dsp (gstreamer_ti). Enrico, Thanks, I'll keep it around for now. Can you please clarify which kernel you use for 35x and 37x platforms? And whether you use the latest versions of other components? The problem with keeping old components around is that they quickly lose compatibility with kernel, toolchain, udev etc. that we use these days and it doesn't make much sense to carry them indefinitely w/o updating or replacing. -- Denys ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2] cmem: Adding New recipe for cmem 2013-11-27 16:55 ` Denys Dmytriyenko @ 2013-11-28 8:20 ` Enrico 0 siblings, 0 replies; 17+ messages in thread From: Enrico @ 2013-11-28 8:20 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: meta-arago@arago-project.org On Wed, Nov 27, 2013 at 5:55 PM, Denys Dmytriyenko <denys@ti.com> wrote: > On Tue, Nov 26, 2013 at 01:56:56PM +0100, Enrico wrote: >> On Wed, Nov 20, 2013 at 4:24 PM, Denys Dmytriyenko <denys@ti.com> wrote: >> > I'd like to see other parts of linuxutils modularized, but that can be done on >> > as needed basis for any of the new platforms when they require those. We can >> > keep the old linuxutils around for a little longer, but it can only be used on >> > the old 35x and 37x plaftorms only and there are many other components (like >> > SGX) removing support for those old platforms already... >> >> Please keep the linuxutils recipe until it can be replaced with the >> modularized ones, it's useful for 35x and 37x dsp (gstreamer_ti). > > Enrico, > > Thanks, I'll keep it around for now. > > Can you please clarify which kernel you use for 35x and 37x platforms? And > whether you use the latest versions of other components? In production i'm using mainline kernel 3.2 with some custom patches (not related to dsp components, see my github at [1]), with unmodified components from meta-ti (i'm not using meta-arago). I'm testing now with kernel 3.12, unmodified components from meta-ti, gcc 4.8.something (angstrom 2013.12), the components need some patching but it was really easy to fix them. I don't remember right now what were the components i needed to fix but i'm sure about cmem and dsplink. Right now the most important feature i'm missing is devicetree bindings for omap3isp. > The problem with keeping old components around is that they quickly lose > compatibility with kernel, toolchain, udev etc. that we use these days and it > doesn't make much sense to carry them indefinitely w/o updating or replacing. I think there are still many users of the omap dsp stuff. I understand that TI doesn't want to put resources on "old" platforms (even if they are still in production and not declared obsolete) but do you think it could be possible to have some help when those kind of problems happen? For example if i have a problem with dsplink and i'm not able to fix it, asking for help in meta-ti will be useful? (i'm speaking about someone in a TI dev team that already knows the code). Enrico [1]: https://github.com/ebutera/meta-igep/blob/master/recipes-kernel/linux/linux_3.2.bb ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2013-11-28 8:20 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-11-07 5:03 [PATCH v2] cmem: Adding New recipe for cmem Sam Nelson 2013-11-07 7:35 ` Maupin, Chase 2013-11-07 11:49 ` Nelson, Sam 2013-11-08 0:33 ` Tivy, Robert 2013-11-08 2:02 ` Denys Dmytriyenko 2013-11-08 1:53 ` Denys Dmytriyenko 2013-11-08 2:00 ` Tivy, Robert 2013-11-08 2:03 ` Denys Dmytriyenko 2013-11-08 2:04 ` Nelson, Sam 2013-11-08 2:06 ` Nelson, Sam 2013-11-12 21:01 ` Nelson, Sam 2013-11-12 21:20 ` Denys Dmytriyenko 2013-11-20 13:11 ` Maupin, Chase 2013-11-20 15:24 ` Denys Dmytriyenko 2013-11-26 12:56 ` Enrico 2013-11-27 16:55 ` Denys Dmytriyenko 2013-11-28 8:20 ` Enrico
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.