On 12/22/17 2:28 PM, Andreas Müller wrote:
On Fri, Dec 22, 2017 at 7:57 PM, Paul Barker <pbar...@toganlabs.com
<mailto:pbar...@toganlabs.com>> wrote:
On Fri, Dec 22, 2017 at 2:17 PM, Andreas Müller
<schnitzelt...@gmail.com <mailto:schnitzelt...@gmail.com>> wrote:
> On Fri, Dec 22, 2017 at 2:25 PM, Andrei Gherzan <and...@gherzan.ro
<mailto:and...@gherzan.ro>> wrote:
>>
>> Hi Andreas,
>>
>> On Thu, Dec 21, 2017 at 8:59 PM, Andreas Müller <schnitzelt...@gmail.com
<mailto:schnitzelt...@gmail.com>>
>> wrote:
>>>
>>>
>>> Why not simply one stable kernel with RT-patches applied if user decides
>>> by an option? That is what I am doing for >1 year now and
meta-raspi-light
>>> is the one which caused me least efforts/headaches of all. And yes I
know I
>>> made life easy here by removing userland completely and taking care for
>>> RPi2/3 only.
>>>
>>
>> I will always advocate against forks but definitely that is an option
too.
>> What I want to understand is why maintaining it in meta-raspberrypi was
>> painful. Basically, the question is how do you currently maintain, rebase
>> etc the rt patch? I would expect it to happen in a git tree as well.
Isn't
>> that the case?
>>
> I maintained it this way:
>
> * Set new kernel version
> * Check if there is an update at RT-Kernel. If so update the patch.
> * Rebuild the kernel. In case a patch does not apply cleanly, I use git
> inside of oe work-shared folder, check/align for hunks failing and insert
> them manually into original patch. From my experience there are usually
very
> few hunks to touch so this is no rocket science.
>
> What do you think?
>
So, my thinking was that if you're going through the effort of getting
the -rt patches to apply to the rpi kernel, I'd like to see that
available to non-OpenEmbedded users. I think a linux-raspberrypi-rt
kernel tree would be a useful think to make available as a standalone
project, which we can then pull into meta-raspberrypi as a simple
recipe.
My complaint with having the entire -rt patch in the meta-raspberrypi
repo was that it's a huge, un-reviewable blob. Multi-thousand line
patches are now less painful with review happening on GitHub now
though - they at least don't upset my email workflow anymore :)
Could you try handling this in git by merging the -rt kernel branch
(https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/log/?h=v4.9-rt
<https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/log/?h=v4.9-rt>)
into the linux-raspberrypi branch regularly instead of by applying the
-rt patch manually? Any merge conflicts could be handled cleanly that
way and it would give us something we could bisect properly in case of
any bugs. The resulting git repository could be published online as
something like 'linux-raspberrypi-rt' if this works.
This is basically my opinion though, there is no one true Right Way
(TM) to do this. If you decide it's still easier for you to handle
this as a patch in the meta-raspberrypi layer then I'm happy to
support that.
Good suggestion - but:
1. you overestimate the RT-patching process / errors caused by RT
2. I would like to keep RT and non-RT kernel versions in sync
3. I see more efforts which don't buy me anything personally
My dislike (3.) might be increased by the fact that I
* (try to) maintain >400 recipes and contribute to others more or less
for 'fun' and due to that I am not keen on some extra duty
* am an old man afraid of changing bad habits :)
However: there is no time pressure on this matter and I am looking
forward to discuss this with you (and others) at FOSDEM. I am sure we'll
find a solution/compromise there.
Perhaps this discussions should be forwarded to rpi community and see if
there is any interest in them maintaining a rt branch for rpi kernel.
Secondly, I wonder how good is upstream mainline kernel for rpi now a
days, we could always have a mainline recipe as an option and use it as
base for things like rt.
Andreas
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
