[yocto] [meta-raspberrypi] linux kernel rt

Khem Raj raj.khem at gmail.com
Thu Jan 25 19:51:29 PST 2018



On 12/22/17 2:28 PM, Andreas Müller wrote:
> On Fri, Dec 22, 2017 at 7:57 PM, Paul Barker <pbarker at toganlabs.com 
> <mailto:pbarker at toganlabs.com>> wrote:
> 
>     On Fri, Dec 22, 2017 at 2:17 PM, Andreas Müller
>     <schnitzeltony at gmail.com <mailto:schnitzeltony at gmail.com>> wrote:
>     > On Fri, Dec 22, 2017 at 2:25 PM, Andrei Gherzan <andrei at gherzan.ro <mailto:andrei at gherzan.ro>> wrote:
>     >>
>     >> Hi Andreas,
>     >>
>     >> On Thu, Dec 21, 2017 at 8:59 PM, Andreas Müller <schnitzeltony at gmail.com <mailto:schnitzeltony at 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
> 



More information about the yocto mailing list