[yocto] [meta-raspberrypi] linux kernel rt

[Andrei Gherzan]

Hi Andreas,

On Thu, Dec 21, 2017 at 8:59 PM, Andreas Müller <schnitzeltony at gmail.com>
wrote:

> On Thu, Dec 21, 2017 at 5:08 PM, Andrei Gherzan <andrei at gherzan.ro> wrote:
>
>> Hi all,
>>
>> On Thu, Dec 14, 2017 at 12:09 PM, Andreas Müller <schnitzeltony at gmail.com
>> > wrote:
>>
>>> On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak <mirza.krak at gmail.com>
>>> wrote:
>>>
>>>> 2017-12-14 9:41 GMT+01:00 Andreas Müller <schnitzeltony at gmail.com>:
>>>> > On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <
>>>> sherifomran2000 at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> hey guys,
>>>> >>
>>>> >> any body tried the real time kernel? I get an error, it is snot in
>>>> the
>>>> >> compatibility list.
>>>> >> can we skip it?
>>>> >>
>>>> >> thanks
>>>> >>
>>>> >> --
>>>> >
>>>> > Good news: I use RT kernel only together with VC4 graphics and have
>>>> lots of
>>>> > fun on PI2/3.
>>>> > Bad news: As far as I know it is not in meta-raspberrypi but in my
>>>> fork [1].
>>>> > There were attempts to land the RT-patches in meta-raspberrypi but
>>>> that was
>>>> > denied for huge patch size :(
>>>>
>>>> If the patch size was the only problem one can pull it by doing the
>>>> following in the recipe:
>>>>
>>>> SRC_URI += " \
>>>>     https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patc
>>>> h-4.9.65-rt56.patch.gz;name=rt-patch
>>>> \
>>>> "
>>>>
>>>> SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95"
>>>> SRC_URI[rt-patch.sha256sum] =
>>>> "47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539"
>>>>
>>>> Note that above sums are "random" and not the for the actually file
>>>> but are there for reference.
>>>>
>>>> That way you do not need to keep a copy of it in meta-raspberrypi.
>>>>
>>>> --
>>>>
>>> Hi Mirza,
>>>
>>> Problem is that patches need alignments sometimes either caused by
>>> Raspberry-Pi-specific adjustments or versions not matching exactly - RT
>>> kernel patch updates are less frequent than kernel updates. Anyway: git is
>>> very good at maintaining huge text content and this should not be a problem
>>> these days. Another discussion about RT kernel was to have an extra kernel
>>> for it and I never understood why. To me that seems nothing but an extra
>>> maintenance burden.
>>>
>>> However - just wrote to Paul: I plan to be at FOSDEM and we can discuss
>>> there how to get back to one layer only (not mine!) making everybody happy
>>> :)
>>>
>>>
>> I remember the discussion. Indeed that was the reason and the
>> recommendation was to maintain a separate linux-raspberry fork where
>> whoever has interest in this will maintain on top of linux-raspberrypi this
>> patch. Obviously that didn't happen but I'd like to see it landing.
>>
>> Yes that was one of the suggestions which made me say 'Thanks - this is
> just additional maintenance burden and will not work for long time - I do
> my own'. FWIW: That suggestion came at a time when you (Andrei) seemed
> overworked totally (just to mention - PLEASE don't take it as criticism - I
> know what I am talking of when it comes to 'overworked').
>

You will be suprised but all of us are busy and this is a side project
handled as good possible in our spare time. I do agree that there was a
time where this project was a little demoted in priority. But even if that
is the case, contributions are always welcomed - as you know.


>
> 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?

--
Andrei Gherzan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20171222/37cd7ceb/attachment.html>