[meta-ti] [thud/master PATCH v2] recipes-bsp: ivshmem-uio: Add new recipe for ivshmem-uio driver

[Khem Raj]

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 <denys at ti.com> 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 <nikhil.nd at ti.com>
>>> 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 <nikhil.nd at ti.com>
>>>>> ---
>>>>> 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.