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

[Björn Brandenburg]

On 30. Oct 2020, at 20:31, Joshua Bakita <jbakita at cs.unc.edu> wrote:
> 
> Nathan Otterness, Leo Chen, and myself have been working on an effort to update LITMUS-RT to Linux 5.4 at UNC. We've been working on-and-off for a few months, but it's finally almost ready!

Excellent! Thank you very much for taking this on. 

> What is the preferred approach to upstreaming a major upgrade like this? Our current tree squashes all the historical LITMUS-RT commits. There's some internal debate as to whether we should convert our tree into a traditional rebase which preserves the LITMUS-RT commit history and modifies each commit as appropriate, or leave it as the squash that it is. Some input from the current LITMUS-RT maintainers would be appreciated.

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. 

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

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? 

Thanks,
Björn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3759 bytes
Desc: not available
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20201106/eb994ebe/attachment.bin>