On Fri, Dec 22, 2017 at 7:57 PM, Paul Barker <pbar...@toganlabs.com> wrote:
> On Fri, Dec 22, 2017 at 2:17 PM, Andreas Müller <schnitzelt...@gmail.com> > wrote: > > On Fri, Dec 22, 2017 at 2:25 PM, Andrei Gherzan <and...@gherzan.ro> > wrote: > >> > >> Hi Andreas, > >> > >> On Thu, Dec 21, 2017 at 8:59 PM, Andreas Müller < > 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-st > able-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. Andreas
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
