[LITMUS^RT] New LITMUS-RT Version Based on Linux 5.4

[Joshua Bakita]

Hello Bjorn,

On Thu, Nov 5, 2020 at 6:34 PM Björn Brandenburg <bbb at mpi-sws.org> wrote:

> In the last couple of releases, I’ve made sure that LITMUS^RT is a
> sequence of logical patches that build on each other. When I was still
> rebasing LITMUS^RT more frequently, this made live a lot easier. I would
> hence suggest to maintain that structure going forward. One giant patch is
> difficult to handle, and as Andrea already pointed out, it loses some
> information (and in particular intent) associated with each commit.


> When rebasing, I’ve squashed fixes and porting commits where it made
> sense, to make the new “fresh” history consist only of semantically
> meaningful, self-contained patches. The complete history of individual
> contributions with original author attribution I have maintained as part of
> the “archive” branches, which you can find on Github. I would suggest to do
> the same here — when the new port is ready, archive the now current branch
> to retain history and make your new clean, partially squashed history on
> top of 5.4 the new current branch.
>

I'll go ahead and rebase our changes to follow this model.


> > We also found a couple bugs in upstream LITMUS-RT while testing our port:
> > 1. GSN-EDF can complete jobs twice when budget enforcement is enabled
>
> Is this fixable with a small patch? If so, it might be nice to also apply
> it to the still-current version.
>

Hopefully, Leo is working on fixing this now. We'll update the list when we
have more info.


> While porting, did you run into any major issues? For instance, any major
> changes in Linux’s scheduler interfaces or kernel APIs that you had to
> adjust the existing codebase to?
>

Yes. Most significantly, pick_next_task() no longer receives prev in the
common case. We've fixed this by substituting current for prev in
pick_next_task_litmus(). In our tests of all the schedulers, that does not
appear to break correctness. High-resolution timers also no longer expire
in a hard IRQ context by default, so all the scheduling timers have changed
to HRTIMER_MODE_ABS_PINNED_HARD (note the addition of _HARD).

Best,

Joshua Bakita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20201111/c82368a3/attachment.html>