On 10/1/19 3:16 PM, Denys Dmytriyenko wrote:
On Tue, Oct 01, 2019 at 02:57:41PM -0700, Khem Raj wrote:
On Tue, Oct 1, 2019 at 1:07 PM Denys Dmytriyenko <[email protected]> wrote:
On Mon, Sep 30, 2019 at 11:41:43PM -0700, Khem Raj wrote:
On Fri, Sep 27, 2019 at 2:17 AM Nikhil Devshatwar <[email protected]>
wrote:
This is external kernel module which enables userspace io over the
Jailhouse ivhsmem (inter VM shared memory)
This driver is useful to test the inter VM communication.
Signed-off-by: Nikhil Devshatwar <[email protected]>
---
Changes from v1:
* Split the ivshmem recipe separately
* Add summary and remove PACKAGE_ARCH define
recipes-bsp/ivshmem-uio/ivshmem-uio-driver_git.bb | 27
+++++++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 recipes-bsp/ivshmem-uio/ivshmem-uio-driver_git.bb
diff --git a/recipes-bsp/ivshmem-uio/ivshmem-uio-driver_git.bb
b/recipes-bsp/ivshmem-uio/ivshmem-uio-driver_git.bb
new file mode 100644
index 0000000..33fb946
--- /dev/null
+++ b/recipes-bsp/ivshmem-uio/ivshmem-uio-driver_git.bb
@@ -0,0 +1,27 @@
+DESCRIPTION = "Kernel driver for IVSHMEM based UIO driver"
+SUMMARY = "Kernel module which registers a UIO (userspace io) device
for inter VM shared memory"
+HOMEPAGE = "https://github.com/henning-schild-work/ivshmem-guest-code
"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM =
"file://COPYING;md5=0546a27aad86c83b75ad4ee6133e9d5e"
+
+inherit module
+
+RDEPENDS_${PN} = "jailhouse"
+
jailhouse is marked as ti-soc specific, so please mark this recipe
ti-soc specific as well. It will help meta-ti to live in a multi-BSP
distros
http://jenkins.nas-admin.org/view/OE/job/oe_world_qemux86-64/1164/consoleFull
if you could test meta-ti patches with one non-ti machine like qemux86
or some such it will help catch this kind of errors
That would only fail when building "world", but thanks for the report.
MACHINE=qemux86 bitbake <recipe> would do it
This would really help the distros
Well, I do know how to break it specifically... :) BTW, building it directly
like that with COMPATIBLE_MACHINE set would also fail with "Nothing PROVIDES"
error.
My point was that people add recipes and expect them to only be included in an
image for their machine. In their view they cannot understand how it would get
into an x86 build on its own, unless someone consciously adds it to their
image. Hence my comment about building "world". And in that case it would be
safely skipped by COMPATIBLE_MACHINE and won't result in an error.
I think this is fine from submitter point of view, Probably, on the
reviewer side, this should be considered as a test to accept a
contribution. I am happy to test your master-next or any other staging
branch that you use for testing meta-ti contribution, provided you will
hold commits and wait for build results from Yoe Distro world builds.
--
_______________________________________________
meta-ti mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-ti
