On 01/07/2018 08:00 PM, Bruce Ashfield wrote: > On Sun, Jan 7, 2018 at 1:57 PM, Marek Vasut <ma...@denx.de> wrote: >> On 01/07/2018 07:55 PM, Bruce Ashfield wrote: >>> On Sun, Jan 7, 2018 at 1:49 PM, Marek Vasut <ma...@denx.de> wrote: >>>> On 01/07/2018 06:55 PM, Bruce Ashfield wrote: >>>>> On Sun, Jan 7, 2018 at 12:53 PM, Marek Vasut <ma...@denx.de> wrote: >>>>>> On 01/07/2018 05:42 PM, Bruce Ashfield wrote: >>>>>>> On Sun, Jan 7, 2018 at 11:38 AM, Marek Vasut <ma...@denx.de> wrote: >>>>>>>> On 01/07/2018 05:37 PM, Bruce Ashfield wrote: >>>>>>>>> On Sun, Jan 7, 2018 at 11:19 AM, Marek Vasut <ma...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
