[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