[PATCH 1/2] xenomai: Add xenomai recipe

[PATCH 1/2] xenomai: Add xenomai recipe

[Marek Vasut]

Add recipe for the xenomai. This recipe is used twice, once to build
the xenomai userspace components and again to patch the kernel with
the cobalt core. Therefore, the xenomai sources are installed into
work-shared rather then work to make them accessible to the kernel
recipe, which triggers the patching.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 meta/recipes-kernel/xenomai/xenomai_git.bb | 54 ++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)
 create mode 100644 meta/recipes-kernel/xenomai/xenomai_git.bb

diff --git a/meta/recipes-kernel/xenomai/xenomai_git.bb b/meta/recipes-kernel/xenomai/xenomai_git.bb
new file mode 100644
index 0000000000..98b371dbda
--- /dev/null
+++ b/meta/recipes-kernel/xenomai/xenomai_git.bb
@@ -0,0 +1,54 @@
+SUMMARY = "Xenomai 3 userspace libraries"
+DESCRIPTION = "Xenomai 3 userspace libraries"
+HOMEPAGE = "http://www.xenomai.org/"
+SECTION = "libs"
+LICENSE = "GPLv2 & LGPLv2.1"
+LIC_FILES_CHKSUM = " \
+	file://include/COPYING;md5=79ed705ccb9481bf9e7026b99f4e2b0e \
+	file://kernel/cobalt/COPYING;md5=073dc31ccb2ebed70db54f1e8aeb4c33 \
+	file://kernel/cobalt/posix/COPYING;md5=073dc31ccb2ebed70db54f1e8aeb4c33 \
+	file://kernel/cobalt/rtdm/COPYING;md5=c99f6e66e37d1cb50ad8be4f5be2ea5d \
+	file://lib/alchemy/COPYING;md5=68ad62c64cc6c620126241fd429e68fe \
+	file://lib/analogy/COPYING;md5=68ad62c64cc6c620126241fd429e68fe \
+	file://lib/boilerplate/COPYING;md5=68ad62c64cc6c620126241fd429e68fe \
+	file://lib/cobalt/COPYING;md5=68ad62c64cc6c620126241fd429e68fe \
+	file://lib/copperplate/COPYING;md5=68ad62c64cc6c620126241fd429e68fe \
+	file://lib/psos/COPYING;md5=68ad62c64cc6c620126241fd429e68fe \
+	file://lib/smokey/COPYING;md5=68ad62c64cc6c620126241fd429e68fe \
+	file://lib/trank/COPYING;md5=68ad62c64cc6c620126241fd429e68fe \
+	file://lib/vxworks/COPYING;md5=68ad62c64cc6c620126241fd429e68fe \
+	"
+
+RDEPENDS_${PN} = "libgcc"
+
+SRC_URI = "git://git.xenomai.org/xenomai-3.git;branch=stable-3.0.x"
+SRCREV="cbc6b87bed0fe7d6d932d943fc8ca0fb49bb5b71"
+
+S = "${TMPDIR}/work-shared/${MACHINE}/xenomai-source"
+B = "${WORKDIR}/build"
+
+inherit autotools pkgconfig
+
+EXTRA_OECONF = "--includedir=${includedir}/${PN} --with-demodir=${bindir}"
+
+do_unpack_extra() {
+	rmdir ${S}
+	mv ${WORKDIR}/git ${S}
+}
+addtask unpack_extra after do_unpack before do_patch
+
+do_install_append() {
+	rmdir ${D}/dev
+}
+
+PACKAGES =+ "${PN}-demo"
+FILES_${PN} += " \
+	${libdir}/cobalt.wrappers ${libdir}/modechk.wrappers \
+	${libdir}/dynlist.ld \
+	"
+FILES_${PN}-demo = " \
+	${bindir}/altency ${bindir}/bufp-label ${bindir}/bufp-readwrite \
+	${bindir}/can_rtt ${bindir}/cross-link ${bindir}/cyclictest \
+	${bindir}/eth_p_all ${bindir}/iddp-label ${bindir}/iddp-sendrecv \
+	${bindir}/xddp-echo ${bindir}/xddp-label ${bindir}/xddp-stream \
+	"
-- 
2.11.0

[PATCH 2/2] kernel: Add optional patch_xenomai task

[Marek Vasut]

Add additional task, do_patch_xenomai, inserted between do_patch and
do_configure tasks. This task applies the cobalt patch to the kernel
sources for a specific machine. This is disabled by default, so use
PACKAGECONFIG[xenomai] of the kernel package to enable the patching.

You will also need a kernel recipe for a kernel version with ipipe
patch applied.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 meta/classes/kernel.bbclass | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index f7b612f84f..70fc39086c 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -481,6 +481,22 @@ do_shared_workdir () {
 	fi
 }
 
+PACKAGECONFIG[xenomai] = ",,"
+
+do_patch_xenomai[depends] += "${@bb.utils.contains('PACKAGECONFIG', 'xenomai', 'xenomai:do_patch', '', d)}"
+do_patch_xenomai() {
+	set +e
+	cd ${S}
+
+	if [ "${@bb.utils.contains('PACKAGECONFIG', 'xenomai', 'yes', 'no', d)}" = "yes" ]; then
+		${TMPDIR}/work-shared/${MACHINE}/xenomai-source/scripts/prepare-kernel.sh \
+			--arch=${TARGET_ARCH} \
+			--linux=${STAGING_KERNEL_DIR} ;
+	fi
+}
+
+addtask patch_xenomai before do_configure after do_patch
+
 # We don't need to stage anything, not the modules/firmware since those would clash with linux-firmware
 sysroot_stage_all () {
 	:
-- 
2.11.0

Re: [PATCH 2/2] kernel: Add optional patch_xenomai task

[Bruce Ashfield]

On Sun, Jan 7, 2018 at 11:19 AM, Marek Vasut <marex@denx.de> wrote:
> Add additional task, do_patch_xenomai, inserted between do_patch and
> do_configure tasks. This task applies the cobalt patch to the kernel
> sources for a specific machine. This is disabled by default, so use
> PACKAGECONFIG[xenomai] of the kernel package to enable the patching.
>
> You will also need a kernel recipe for a kernel version with ipipe
> patch applied.

This doesn't make any sense to me.

Why on earth would this be in kernel.bbclass ? and part of a xenomai
recipe ?

Bruce

>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  meta/classes/kernel.bbclass | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index f7b612f84f..70fc39086c 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -481,6 +481,22 @@ do_shared_workdir () {
>         fi
>  }
>
> +PACKAGECONFIG[xenomai] = ",,"
> +
> +do_patch_xenomai[depends] += "${@bb.utils.contains('PACKAGECONFIG', 'xenomai', 'xenomai:do_patch', '', d)}"
> +do_patch_xenomai() {
> +       set +e
> +       cd ${S}
> +
> +       if [ "${@bb.utils.contains('PACKAGECONFIG', 'xenomai', 'yes', 'no', d)}" = "yes" ]; then
> +               ${TMPDIR}/work-shared/${MACHINE}/xenomai-source/scripts/prepare-kernel.sh \
> +                       --arch=${TARGET_ARCH} \
> +                       --linux=${STAGING_KERNEL_DIR} ;
> +       fi
> +}
> +
> +addtask patch_xenomai before do_configure after do_patch
> +
>  # We don't need to stage anything, not the modules/firmware since those would clash with linux-firmware
>  sysroot_stage_all () {
>         :
> --
> 2.11.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 2/2] kernel: Add optional patch_xenomai task

[Marek Vasut]

On 01/07/2018 05:37 PM, Bruce Ashfield wrote:
> On Sun, Jan 7, 2018 at 11:19 AM, Marek Vasut <marex@denx.de> wrote:
>> Add additional task, do_patch_xenomai, inserted between do_patch and
>> do_configure tasks. This task applies the cobalt patch to the kernel
>> sources for a specific machine. This is disabled by default, so use
>> PACKAGECONFIG[xenomai] of the kernel package to enable the patching.
>>
>> You will also need a kernel recipe for a kernel version with ipipe
>> patch applied.
> 
> This doesn't make any sense to me.
> 
> Why on earth would this be in kernel.bbclass ? and part of a xenomai
> recipe ?
Do you have a better suggestion how to make this easily available for
every kernel recipe ?

-- 
Best regards,
Marek Vasut

Re: [PATCH 2/2] kernel: Add optional patch_xenomai task

[Bruce Ashfield]

On Sun, Jan 7, 2018 at 11:38 AM, Marek Vasut <marex@denx.de> wrote:
> On 01/07/2018 05:37 PM, Bruce Ashfield wrote:
>> On Sun, Jan 7, 2018 at 11:19 AM, Marek Vasut <marex@denx.de> wrote:
>>> Add additional task, do_patch_xenomai, inserted between do_patch and
>>> do_configure tasks. This task applies the cobalt patch to the kernel
>>> sources for a specific machine. This is disabled by default, so use
>>> PACKAGECONFIG[xenomai] of the kernel package to enable the patching.
>>>
>>> You will also need a kernel recipe for a kernel version with ipipe
>>> patch applied.
>>
>> This doesn't make any sense to me.
>>
>> Why on earth would this be in kernel.bbclass ? and part of a xenomai
>> recipe ?
> Do you have a better suggestion how to make this easily available for
> every kernel recipe ?

There's no need to make it available for every kernel recipe. If someone
wants to build xenomai, they need to have a specific kernel recipe and
configuration to make it work. By providing that patch and allowing it to
be applied to any kernel doesn't mean it will actually work .. so you aren't
doing anyone any favours.

The same thing could be said for the -rt patch, aufs, etc, any patch could
be made available for any kernel, but they aren't, since they will either fail
to patch, or won't work at runtime.

Why would a specific xenomai "host" kernel recipe be made and have that
patch applied ? You need to control the kernel version and configuration
for it to work at runtime anyway.

Bruce

>
> --
> Best regards,
> Marek Vasut



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 2/2] kernel: Add optional patch_xenomai task

[Bruce Ashfield]

On Sun, Jan 7, 2018 at 11:42 AM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> On Sun, Jan 7, 2018 at 11:38 AM, Marek Vasut <marex@denx.de> wrote:
>> On 01/07/2018 05:37 PM, Bruce Ashfield wrote:
>>> On Sun, Jan 7, 2018 at 11:19 AM, Marek Vasut <marex@denx.de> wrote:
>>>> Add additional task, do_patch_xenomai, inserted between do_patch and
>>>> do_configure tasks. This task applies the cobalt patch to the kernel
>>>> sources for a specific machine. This is disabled by default, so use
>>>> PACKAGECONFIG[xenomai] of the kernel package to enable the patching.
>>>>
>>>> You will also need a kernel recipe for a kernel version with ipipe
>>>> patch applied.
>>>
>>> This doesn't make any sense to me.
>>>
>>> Why on earth would this be in kernel.bbclass ? and part of a xenomai
>>> recipe ?
>> Do you have a better suggestion how to make this easily available for
>> every kernel recipe ?
>
> There's no need to make it available for every kernel recipe. If someone
> wants to build xenomai, they need to have a specific kernel recipe and
> configuration to make it work. By providing that patch and allowing it to
> be applied to any kernel doesn't mean it will actually work .. so you aren't
> doing anyone any favours.
>
> The same thing could be said for the -rt patch, aufs, etc, any patch could
> be made available for any kernel, but they aren't, since they will either fail
> to patch, or won't work at runtime.
>
> Why would a specific xenomai "host" kernel recipe be made and have that
> patch applied ? You need to control the kernel version and configuration
> for it to work at runtime anyway.

but of course, if RP thinks this is ok .. then it is ok.

I've done Xenomai in the past, and have maintained a separate recipe
for the parts. So I'm speaking for that experience and for what I've done
to maintain various kernel variants in oe based distros.

Bruce

>
> Bruce
>
>>
>> --
>> Best regards,
>> Marek Vasut
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 1/2] xenomai: Add xenomai recipe

[Alexander Kanavin]

On 01/07/2018 06:19 PM, Marek Vasut wrote:
> Add recipe for the xenomai. This recipe is used twice, once to build
> the xenomai userspace components and again to patch the kernel with
> the cobalt core. Therefore, the xenomai sources are installed into
> work-shared rather then work to make them accessible to the kernel
> recipe, which triggers the patching.

What is xenomai? What is a 'cobalt core'? What do they do and who would 
want to use them? Please do explain that in the commit message.

> +SUMMARY = "Xenomai 3 userspace libraries"
> +DESCRIPTION = "Xenomai 3 userspace libraries"

... and here - description cannot be the same as the summary.

Alex

Re: [PATCH 2/2] kernel: Add optional patch_xenomai task

[Marek Vasut]

On 01/07/2018 05:42 PM, Bruce Ashfield wrote:
> On Sun, Jan 7, 2018 at 11:38 AM, Marek Vasut <marex@denx.de> wrote:
>> On 01/07/2018 05:37 PM, Bruce Ashfield wrote:
>>> On Sun, Jan 7, 2018 at 11:19 AM, Marek Vasut <marex@denx.de> wrote:
>>>> Add additional task, do_patch_xenomai, inserted between do_patch and
>>>> do_configure tasks. This task applies the cobalt patch to the kernel
>>>> sources for a specific machine. This is disabled by default, so use
>>>> PACKAGECONFIG[xenomai] of the kernel package to enable the patching.
>>>>
>>>> You will also need a kernel recipe for a kernel version with ipipe
>>>> patch applied.
>>>
>>> This doesn't make any sense to me.
>>>
>>> Why on earth would this be in kernel.bbclass ? and part of a xenomai
>>> recipe ?
>> Do you have a better suggestion how to make this easily available for
>> every kernel recipe ?
> 
> There's no need to make it available for every kernel recipe. If someone
> wants to build xenomai, they need to have a specific kernel recipe and
> configuration to make it work. By providing that patch and allowing it to
> be applied to any kernel doesn't mean it will actually work .. so you aren't
> doing anyone any favours.
> 
> The same thing could be said for the -rt patch, aufs, etc, any patch could
> be made available for any kernel, but they aren't, since they will either fail
> to patch, or won't work at runtime.
We actually have a -rt patch available in the kernel recipes, so why not
xenomai patch ?

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/2] xenomai: Add xenomai recipe

[Marek Vasut]

On 01/07/2018 06:17 PM, Alexander Kanavin wrote:
> On 01/07/2018 06:19 PM, Marek Vasut wrote:
>> Add recipe for the xenomai. This recipe is used twice, once to build
>> the xenomai userspace components and again to patch the kernel with
>> the cobalt core. Therefore, the xenomai sources are installed into
>> work-shared rather then work to make them accessible to the kernel
>> recipe, which triggers the patching.
> 
> What is xenomai? What is a 'cobalt core'? What do they do and who would
> want to use them? Please do explain that in the commit message.

I guess the link in the xenomai recipe explains it, details are here:
http://xenomai.org/installing-xenomai-3-x/

>> +SUMMARY = "Xenomai 3 userspace libraries"
>> +DESCRIPTION = "Xenomai 3 userspace libraries"
> 
> ... and here - description cannot be the same as the summary.

So do I remove one of them or what's the difference really ?

> Alex


-- 
Best regards,
Marek Vasut

Re: [PATCH 2/2] kernel: Add optional patch_xenomai task

[Bruce Ashfield]

On Sun, Jan 7, 2018 at 12:53 PM, Marek Vasut <marex@denx.de> wrote:
> On 01/07/2018 05:42 PM, Bruce Ashfield wrote:
>> On Sun, Jan 7, 2018 at 11:38 AM, Marek Vasut <marex@denx.de> wrote:
>>> On 01/07/2018 05:37 PM, Bruce Ashfield wrote:
>>>> On Sun, Jan 7, 2018 at 11:19 AM, Marek Vasut <marex@denx.de> wrote:
>>>>> Add additional task, do_patch_xenomai, inserted between do_patch and
>>>>> do_configure tasks. This task applies the cobalt patch to the kernel
>>>>> sources for a specific machine. This is disabled by default, so use
>>>>> PACKAGECONFIG[xenomai] of the kernel package to enable the patching.
>>>>>
>>>>> You will also need a kernel recipe for a kernel version with ipipe
>>>>> patch applied.
>>>>
>>>> This doesn't make any sense to me.
>>>>
>>>> Why on earth would this be in kernel.bbclass ? and part of a xenomai
>>>> recipe ?
>>> Do you have a better suggestion how to make this easily available for
>>> every kernel recipe ?
>>
>> There's no need to make it available for every kernel recipe. If someone
>> wants to build xenomai, they need to have a specific kernel recipe and
>> configuration to make it work. By providing that patch and allowing it to
>> be applied to any kernel doesn't mean it will actually work .. so you aren't
>> doing anyone any favours.
>>
>> The same thing could be said for the -rt patch, aufs, etc, any patch could
>> be made available for any kernel, but they aren't, since they will either fail
>> to patch, or won't work at runtime.
> We actually have a -rt patch available in the kernel recipes, so why not
> xenomai patch ?

As a separate recipe, not as something in a common bbclass, which implies
that it applies and works everywhere.

Anyone that is trying to apply -rt against a generic kernel .. is very mistaken.

Bruce

>
> --
> Best regards,
> Marek Vasut



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 2/2] kernel: Add optional patch_xenomai task

[Marek Vasut]

On 01/07/2018 06:55 PM, Bruce Ashfield wrote:
> On Sun, Jan 7, 2018 at 12:53 PM, Marek Vasut <marex@denx.de> wrote:
>> On 01/07/2018 05:42 PM, Bruce Ashfield wrote:
>>> On Sun, Jan 7, 2018 at 11:38 AM, Marek Vasut <marex@denx.de> wrote:
>>>> On 01/07/2018 05:37 PM, Bruce Ashfield wrote:
>>>>> On Sun, Jan 7, 2018 at 11:19 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>> Add additional task, do_patch_xenomai, inserted between do_patch and
>>>>>> do_configure tasks. This task applies the cobalt patch to the kernel
>>>>>> sources for a specific machine. This is disabled by default, so use
>>>>>> PACKAGECONFIG[xenomai] of the kernel package to enable the patching.
>>>>>>
>>>>>> You will also need a kernel recipe for a kernel version with ipipe
>>>>>> patch applied.
>>>>>
>>>>> This doesn't make any sense to me.
>>>>>
>>>>> Why on earth would this be in kernel.bbclass ? and part of a xenomai
>>>>> recipe ?
>>>> Do you have a better suggestion how to make this easily available for
>>>> every kernel recipe ?
>>>
>>> There's no need to make it available for every kernel recipe. If someone
>>> wants to build xenomai, they need to have a specific kernel recipe and
>>> configuration to make it work. By providing that patch and allowing it to
>>> be applied to any kernel doesn't mean it will actually work .. so you aren't
>>> doing anyone any favours.
>>>
>>> The same thing could be said for the -rt patch, aufs, etc, any patch could
>>> be made available for any kernel, but they aren't, since they will either fail
>>> to patch, or won't work at runtime.
>> We actually have a -rt patch available in the kernel recipes, so why not
>> xenomai patch ?
> 
> As a separate recipe, not as something in a common bbclass, which implies
> that it applies and works everywhere.
> 
> Anyone that is trying to apply -rt against a generic kernel .. is very mistaken.

So I should pull this into linux-*-xenomai , just like the rt patch does?

-- 
Best regards,
Marek Vasut

Re: [PATCH 2/2] kernel: Add optional patch_xenomai task

[Bruce Ashfield]

On Sun, Jan 7, 2018 at 1:49 PM, Marek Vasut <marex@denx.de> wrote:
> On 01/07/2018 06:55 PM, Bruce Ashfield wrote:
>> On Sun, Jan 7, 2018 at 12:53 PM, Marek Vasut <marex@denx.de> wrote:
>>> On 01/07/2018 05:42 PM, Bruce Ashfield wrote:
>>>> On Sun, Jan 7, 2018 at 11:38 AM, Marek Vasut <marex@denx.de> wrote:
>>>>> On 01/07/2018 05:37 PM, Bruce Ashfield wrote:
>>>>>> On Sun, Jan 7, 2018 at 11:19 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>>> Add additional task, do_patch_xenomai, inserted between do_patch and
>>>>>>> do_configure tasks. This task applies the cobalt patch to the kernel
>>>>>>> sources for a specific machine. This is disabled by default, so use
>>>>>>> PACKAGECONFIG[xenomai] of the kernel package to enable the patching.
>>>>>>>
>>>>>>> You will also need a kernel recipe for a kernel version with ipipe
>>>>>>> patch applied.
>>>>>>
>>>>>> This doesn't make any sense to me.
>>>>>>
>>>>>> Why on earth would this be in kernel.bbclass ? and part of a xenomai
>>>>>> recipe ?
>>>>> Do you have a better suggestion how to make this easily available for
>>>>> every kernel recipe ?
>>>>
>>>> There's no need to make it available for every kernel recipe. If someone
>>>> wants to build xenomai, they need to have a specific kernel recipe and
>>>> configuration to make it work. By providing that patch and allowing it to
>>>> be applied to any kernel doesn't mean it will actually work .. so you aren't
>>>> doing anyone any favours.
>>>>
>>>> The same thing could be said for the -rt patch, aufs, etc, any patch could
>>>> be made available for any kernel, but they aren't, since they will either fail
>>>> to patch, or won't work at runtime.
>>> We actually have a -rt patch available in the kernel recipes, so why not
>>> xenomai patch ?
>>
>> As a separate recipe, not as something in a common bbclass, which implies
>> that it applies and works everywhere.
>>
>> Anyone that is trying to apply -rt against a generic kernel .. is very mistaken.
>
> So I should pull this into linux-*-xenomai , just like the rt patch does?

Yep.

But how it is maintained is a RP question, oe-core has a set of reference kernel
versions, and those reference kernels have a similar set of functionality across
architectures, are actively maintained and all get the same fixes at
the same time.

(and I just realized that RP isn't copied on this thread anymore, so I'm adding
him).

If we introduce something like this, I'd argue that it needs to follow the same
kernel versions to be consistent with the other oe-core references.

That is a question for the steering committee and the architecture mailing list.

So while that happens, why not just put this in a meta-xenomai for the time
being and once all the details have been hammered out, it could merge.

Cheers,

Bruce

>
> --
> Best regards,
> Marek Vasut



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 2/2] kernel: Add optional patch_xenomai task

[Marek Vasut]

On 01/07/2018 07:55 PM, Bruce Ashfield wrote:
> On Sun, Jan 7, 2018 at 1:49 PM, Marek Vasut <marex@denx.de> wrote:
>> On 01/07/2018 06:55 PM, Bruce Ashfield wrote:
>>> On Sun, Jan 7, 2018 at 12:53 PM, Marek Vasut <marex@denx.de> wrote:
>>>> On 01/07/2018 05:42 PM, Bruce Ashfield wrote:
>>>>> On Sun, Jan 7, 2018 at 11:38 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>> On 01/07/2018 05:37 PM, Bruce Ashfield wrote:
>>>>>>> On Sun, Jan 7, 2018 at 11:19 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>>>> Add additional task, do_patch_xenomai, inserted between do_patch and
>>>>>>>> do_configure tasks. This task applies the cobalt patch to the kernel
>>>>>>>> sources for a specific machine. This is disabled by default, so use
>>>>>>>> PACKAGECONFIG[xenomai] of the kernel package to enable the patching.
>>>>>>>>
>>>>>>>> You will also need a kernel recipe for a kernel version with ipipe
>>>>>>>> patch applied.
>>>>>>>
>>>>>>> This doesn't make any sense to me.
>>>>>>>
>>>>>>> Why on earth would this be in kernel.bbclass ? and part of a xenomai
>>>>>>> recipe ?
>>>>>> Do you have a better suggestion how to make this easily available for
>>>>>> every kernel recipe ?
>>>>>
>>>>> There's no need to make it available for every kernel recipe. If someone
>>>>> wants to build xenomai, they need to have a specific kernel recipe and
>>>>> configuration to make it work. By providing that patch and allowing it to
>>>>> be applied to any kernel doesn't mean it will actually work .. so you aren't
>>>>> doing anyone any favours.
>>>>>
>>>>> The same thing could be said for the -rt patch, aufs, etc, any patch could
>>>>> be made available for any kernel, but they aren't, since they will either fail
>>>>> to patch, or won't work at runtime.
>>>> We actually have a -rt patch available in the kernel recipes, so why not
>>>> xenomai patch ?
>>>
>>> As a separate recipe, not as something in a common bbclass, which implies
>>> that it applies and works everywhere.
>>>
>>> Anyone that is trying to apply -rt against a generic kernel .. is very mistaken.
>>
>> So I should pull this into linux-*-xenomai , just like the rt patch does?
> 
> Yep.
> 
> But how it is maintained is a RP question, oe-core has a set of reference kernel
> versions, and those reference kernels have a similar set of functionality across
> architectures, are actively maintained and all get the same fixes at
> the same time.
> 
> (and I just realized that RP isn't copied on this thread anymore, so I'm adding
> him).
> 
> If we introduce something like this, I'd argue that it needs to follow the same
> kernel versions to be consistent with the other oe-core references.
> 
> That is a question for the steering committee and the architecture mailing list.
> 
> So while that happens, why not just put this in a meta-xenomai for the time
> being and once all the details have been hammered out, it could merge.
That's fine by me, although the main feedback I'm currently interested
in is whether this has any chance of getting included in oe-core and if
there are some other big issues with this .

-- 
Best regards,
Marek Vasut

Re: [PATCH 2/2] kernel: Add optional patch_xenomai task

[Bruce Ashfield]

On Sun, Jan 7, 2018 at 1:57 PM, Marek Vasut <marex@denx.de> wrote:
> On 01/07/2018 07:55 PM, Bruce Ashfield wrote:
>> On Sun, Jan 7, 2018 at 1:49 PM, Marek Vasut <marex@denx.de> wrote:
>>> On 01/07/2018 06:55 PM, Bruce Ashfield wrote:
>>>> On Sun, Jan 7, 2018 at 12:53 PM, Marek Vasut <marex@denx.de> wrote:
>>>>> On 01/07/2018 05:42 PM, Bruce Ashfield wrote:
>>>>>> On Sun, Jan 7, 2018 at 11:38 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>>> On 01/07/2018 05:37 PM, Bruce Ashfield wrote:
>>>>>>>> On Sun, Jan 7, 2018 at 11:19 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>>>>> Add additional task, do_patch_xenomai, inserted between do_patch and
>>>>>>>>> do_configure tasks. This task applies the cobalt patch to the kernel
>>>>>>>>> sources for a specific machine. This is disabled by default, so use
>>>>>>>>> PACKAGECONFIG[xenomai] of the kernel package to enable the patching.
>>>>>>>>>
>>>>>>>>> You will also need a kernel recipe for a kernel version with ipipe
>>>>>>>>> patch applied.
>>>>>>>>
>>>>>>>> This doesn't make any sense to me.
>>>>>>>>
>>>>>>>> Why on earth would this be in kernel.bbclass ? and part of a xenomai
>>>>>>>> recipe ?
>>>>>>> Do you have a better suggestion how to make this easily available for
>>>>>>> every kernel recipe ?
>>>>>>
>>>>>> There's no need to make it available for every kernel recipe. If someone
>>>>>> wants to build xenomai, they need to have a specific kernel recipe and
>>>>>> configuration to make it work. By providing that patch and allowing it to
>>>>>> be applied to any kernel doesn't mean it will actually work .. so you aren't
>>>>>> doing anyone any favours.
>>>>>>
>>>>>> The same thing could be said for the -rt patch, aufs, etc, any patch could
>>>>>> be made available for any kernel, but they aren't, since they will either fail
>>>>>> to patch, or won't work at runtime.
>>>>> We actually have a -rt patch available in the kernel recipes, so why not
>>>>> xenomai patch ?
>>>>
>>>> As a separate recipe, not as something in a common bbclass, which implies
>>>> that it applies and works everywhere.
>>>>
>>>> Anyone that is trying to apply -rt against a generic kernel .. is very mistaken.
>>>
>>> So I should pull this into linux-*-xenomai , just like the rt patch does?
>>
>> Yep.
>>
>> But how it is maintained is a RP question, oe-core has a set of reference kernel
>> versions, and those reference kernels have a similar set of functionality across
>> architectures, are actively maintained and all get the same fixes at
>> the same time.
>>
>> (and I just realized that RP isn't copied on this thread anymore, so I'm adding
>> him).
>>
>> If we introduce something like this, I'd argue that it needs to follow the same
>> kernel versions to be consistent with the other oe-core references.
>>
>> That is a question for the steering committee and the architecture mailing list.
>>
>> So while that happens, why not just put this in a meta-xenomai for the time
>> being and once all the details have been hammered out, it could merge.
> That's fine by me, although the main feedback I'm currently interested
> in is whether this has any chance of getting included in oe-core and if
> there are some other big issues with this .

There has been interest in this in the past, which is why I've gone down the
route of getting things up and running myself.

The real feedback and feasibility would be in those other forums, but if done
right, I don't see why not myself.

Bruce

>
> --
> Best regards,
> Marek Vasut



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 1/2] xenomai: Add xenomai recipe

[Alexander Kanavin]

On 01/07/2018 07:55 PM, Marek Vasut wrote:
>>> Add recipe for the xenomai. This recipe is used twice, once to build
>>> the xenomai userspace components and again to patch the kernel with
>>> the cobalt core. Therefore, the xenomai sources are installed into
>>> work-shared rather then work to make them accessible to the kernel
>>> recipe, which triggers the patching.
>>
>> What is xenomai? What is a 'cobalt core'? What do they do and who would
>> want to use them? Please do explain that in the commit message.
> 
> I guess the link in the xenomai recipe explains it, details are here:
> http://xenomai.org/installing-xenomai-3-x/

I need to clarify: all of these questions need to be answered in the 
context of oe-core. Essentially, you need to explain why the recipe 
should be in oe-core and not in its own layer.

>>> +SUMMARY = "Xenomai 3 userspace libraries"
>>> +DESCRIPTION = "Xenomai 3 userspace libraries"
>>
>> ... and here - description cannot be the same as the summary.
> 
> So do I remove one of them or what's the difference really ?

Same as the difference between commit summary and commit message. 
Description usually spans several lines, and provides fully formed 
sentences that explain what the software provided by the recipe does.

Also, an update to maintainers.inc would be appreciated, when adding new 
recipes.


Alex

Re: [PATCH 1/2] xenomai: Add xenomai recipe

[Marek Vasut]

On 01/07/2018 08:27 PM, Alexander Kanavin wrote:
> On 01/07/2018 07:55 PM, Marek Vasut wrote:
>>>> Add recipe for the xenomai. This recipe is used twice, once to build
>>>> the xenomai userspace components and again to patch the kernel with
>>>> the cobalt core. Therefore, the xenomai sources are installed into
>>>> work-shared rather then work to make them accessible to the kernel
>>>> recipe, which triggers the patching.
>>>
>>> What is xenomai? What is a 'cobalt core'? What do they do and who would
>>> want to use them? Please do explain that in the commit message.
>>
>> I guess the link in the xenomai recipe explains it, details are here:
>> http://xenomai.org/installing-xenomai-3-x/
> 
> I need to clarify: all of these questions need to be answered in the
> context of oe-core. Essentially, you need to explain why the recipe
> should be in oe-core and not in its own layer.

Same rationale as for having linux-*-rt with preempt-rt patch.

>>>> +SUMMARY = "Xenomai 3 userspace libraries"
>>>> +DESCRIPTION = "Xenomai 3 userspace libraries"
>>>
>>> ... and here - description cannot be the same as the summary.
>>
>> So do I remove one of them or what's the difference really ?
> 
> Same as the difference between commit summary and commit message.
> Description usually spans several lines, and provides fully formed
> sentences that explain what the software provided by the recipe does.
> 
> Also, an update to maintainers.inc would be appreciated, when adding new
> recipes.

Fine

-- 
Best regards,
Marek Vasut

Re: [PATCH 2/2] kernel: Add optional patch_xenomai task

[Marek Vasut]

On 01/07/2018 08:00 PM, Bruce Ashfield wrote:
> On Sun, Jan 7, 2018 at 1:57 PM, Marek Vasut <marex@denx.de> wrote:
>> On 01/07/2018 07:55 PM, Bruce Ashfield wrote:
>>> On Sun, Jan 7, 2018 at 1:49 PM, Marek Vasut <marex@denx.de> wrote:
>>>> On 01/07/2018 06:55 PM, Bruce Ashfield wrote:
>>>>> On Sun, Jan 7, 2018 at 12:53 PM, Marek Vasut <marex@denx.de> wrote:
>>>>>> On 01/07/2018 05:42 PM, Bruce Ashfield wrote:
>>>>>>> On Sun, Jan 7, 2018 at 11:38 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>>>> On 01/07/2018 05:37 PM, Bruce Ashfield wrote:
>>>>>>>>> On Sun, Jan 7, 2018 at 11:19 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>>>>>> Add additional task, do_patch_xenomai, inserted between do_patch and
>>>>>>>>>> do_configure tasks. This task applies the cobalt patch to the kernel
>>>>>>>>>> sources for a specific machine. This is disabled by default, so use
>>>>>>>>>> PACKAGECONFIG[xenomai] of the kernel package to enable the patching.
>>>>>>>>>>
>>>>>>>>>> You will also need a kernel recipe for a kernel version with ipipe
>>>>>>>>>> patch applied.
>>>>>>>>>
>>>>>>>>> This doesn't make any sense to me.
>>>>>>>>>
>>>>>>>>> Why on earth would this be in kernel.bbclass ? and part of a xenomai
>>>>>>>>> recipe ?
>>>>>>>> Do you have a better suggestion how to make this easily available for
>>>>>>>> every kernel recipe ?
>>>>>>>
>>>>>>> There's no need to make it available for every kernel recipe. If someone
>>>>>>> wants to build xenomai, they need to have a specific kernel recipe and
>>>>>>> configuration to make it work. By providing that patch and allowing it to
>>>>>>> be applied to any kernel doesn't mean it will actually work .. so you aren't
>>>>>>> doing anyone any favours.
>>>>>>>
>>>>>>> The same thing could be said for the -rt patch, aufs, etc, any patch could
>>>>>>> be made available for any kernel, but they aren't, since they will either fail
>>>>>>> to patch, or won't work at runtime.
>>>>>> We actually have a -rt patch available in the kernel recipes, so why not
>>>>>> xenomai patch ?
>>>>>
>>>>> As a separate recipe, not as something in a common bbclass, which implies
>>>>> that it applies and works everywhere.
>>>>>
>>>>> Anyone that is trying to apply -rt against a generic kernel .. is very mistaken.
>>>>
>>>> So I should pull this into linux-*-xenomai , just like the rt patch does?
>>>
>>> Yep.
>>>
>>> But how it is maintained is a RP question, oe-core has a set of reference kernel
>>> versions, and those reference kernels have a similar set of functionality across
>>> architectures, are actively maintained and all get the same fixes at
>>> the same time.
>>>
>>> (and I just realized that RP isn't copied on this thread anymore, so I'm adding
>>> him).
>>>
>>> If we introduce something like this, I'd argue that it needs to follow the same
>>> kernel versions to be consistent with the other oe-core references.
>>>
>>> That is a question for the steering committee and the architecture mailing list.
>>>
>>> So while that happens, why not just put this in a meta-xenomai for the time
>>> being and once all the details have been hammered out, it could merge.
>> That's fine by me, although the main feedback I'm currently interested
>> in is whether this has any chance of getting included in oe-core and if
>> there are some other big issues with this .
> 
> There has been interest in this in the past, which is why I've gone down the
> route of getting things up and running myself.
> 
> The real feedback and feasibility would be in those other forums, but if done
> right, I don't see why not myself.

OK fine, so let's see.

-- 
Best regards,
Marek Vasut

Re: [PATCH 2/2] kernel: Add optional patch_xenomai task

[akuster808]

On 01/07/2018 10:57 AM, Marek Vasut wrote:
> On 01/07/2018 07:55 PM, Bruce Ashfield wrote:
>> On Sun, Jan 7, 2018 at 1:49 PM, Marek Vasut <marex@denx.de> wrote:
>>> On 01/07/2018 06:55 PM, Bruce Ashfield wrote:
>>>> On Sun, Jan 7, 2018 at 12:53 PM, Marek Vasut <marex@denx.de> wrote:
>>>>> On 01/07/2018 05:42 PM, Bruce Ashfield wrote:
>>>>>> On Sun, Jan 7, 2018 at 11:38 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>>> On 01/07/2018 05:37 PM, Bruce Ashfield wrote:
>>>>>>>> On Sun, Jan 7, 2018 at 11:19 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>>>>> Add additional task, do_patch_xenomai, inserted between do_patch and
>>>>>>>>> do_configure tasks. This task applies the cobalt patch to the kernel
>>>>>>>>> sources for a specific machine. This is disabled by default, so use
>>>>>>>>> PACKAGECONFIG[xenomai] of the kernel package to enable the patching.
>>>>>>>>>
>>>>>>>>> You will also need a kernel recipe for a kernel version with ipipe
>>>>>>>>> patch applied.
>>>>>>>> This doesn't make any sense to me.
>>>>>>>>
>>>>>>>> Why on earth would this be in kernel.bbclass ? and part of a xenomai
>>>>>>>> recipe ?
>>>>>>> Do you have a better suggestion how to make this easily available for
>>>>>>> every kernel recipe ?
>>>>>> There's no need to make it available for every kernel recipe. If someone
>>>>>> wants to build xenomai, they need to have a specific kernel recipe and
>>>>>> configuration to make it work. By providing that patch and allowing it to
>>>>>> be applied to any kernel doesn't mean it will actually work .. so you aren't
>>>>>> doing anyone any favours.
>>>>>>
>>>>>> The same thing could be said for the -rt patch, aufs, etc, any patch could
>>>>>> be made available for any kernel, but they aren't, since they will either fail
>>>>>> to patch, or won't work at runtime.
>>>>> We actually have a -rt patch available in the kernel recipes, so why not
>>>>> xenomai patch ?
>>>> As a separate recipe, not as something in a common bbclass, which implies
>>>> that it applies and works everywhere.
>>>>
>>>> Anyone that is trying to apply -rt against a generic kernel .. is very mistaken.
>>> So I should pull this into linux-*-xenomai , just like the rt patch does?
>> Yep.
>>
>> But how it is maintained is a RP question, oe-core has a set of reference kernel
>> versions, and those reference kernels have a similar set of functionality across
>> architectures, are actively maintained and all get the same fixes at
>> the same time.
>>
>> (and I just realized that RP isn't copied on this thread anymore, so I'm adding
>> him).
>>
>> If we introduce something like this, I'd argue that it needs to follow the same
>> kernel versions to be consistent with the other oe-core references.
>>
>> That is a question for the steering committee and the architecture mailing list.
>>
>> So while that happens, why not just put this in a meta-xenomai for the time
>> being and once all the details have been hammered out, it could merge.
> That's fine by me, although the main feedback I'm currently interested
> in is whether this has any chance of getting included in oe-core and if
> there are some other big issues with this .
>

My biggest concern is who will keep this maintained in Master and in
stable branches? Do we need to add this to the test matrix? Adding
things to Core has a different set of requirements than other layers.

- armin