<div dir="ltr"><div>Hello <span class="gmail-il">LITMUS</span>^RT developers and users,</div><div><br></div>I'm excited to announce that the second release candidate of LITMUS^RT rebased<br>on Linux 5.4 is now available for testing! The sources are available in the<br>linux-5.4-litmus branch on <a href="https://github.com/JoshuaJB/litmus-rt.git">https://github.com/JoshuaJB/litmus-rt.git</a>.<br><br>Changes made during the rebase from Linux 4.9.30 to 5.4.224:<br>- Make miscellaneous whitespace cleanup and include fixes.<br>- Correct for minor changes in type and function names.<br>- Switch from sys_kill() to do_send_sig_info().<br>- Add _HARD postfix to relevant LITMUS^RT hrtimers for PREEMPT-RT support.<br>- Add a dummy balance function to kernel/sched/litmus.c.<br>- set_curr_task() was renamed set_next_task() upstream. Reflect here.<br>- Adjust pick_next_task_litmus() to use rq->curr instead of prev since we no<br>  longer get a valid version of prev. Our logic cannot be moved to the new<br>  balance function, as that's not called when CONFIG_SMP is disabled.<br>- Remove put_prev_task() call from pick_next_task_litmus(), as this is now<br>  automatically invoked by our caller. This implies that put_prev_task() is now<br>  called more often than before, but there's nothing that can be done about<br>  that without adding special-case logic in kernel/sched/core.c.<br>- Remove lockdep_unpin_lock() and lockdep_repin_lock() invocations from<br>  litmus_pick_next_task() as that function is no longer passed a non-NULL<br>  rf->cookie. See earlier note about why we can't move the logic of this<br>  function to balance_litmus(). These calls are merely annotations which<br>  validate lock state, and are not strictly necessary (see<br>  doc/Documention/locking/lockdep-design.txt).<br>- Adjust for restructure of smp_reschedule_interrupt().<br>- set_next_task() in every scheduling class now takes a `first` parameter. This<br>  seems to be safe to ignore in SCHED_LITMUS.<br>- The mutex owner field is now atomic (see upstream commit<br>  3ca0ff571b092ee4d807f1168caa428d95b0173b), so we no longer need to handle the<br>  preemption case and check for is_realtime().<br>- Conditionally set the next-lowest-priority scheduling class in SCHED_LITMUS<br>  as stop_sched_class is now only used if CONFIG_SMP.<br>- Stop requesting the tv64 field from ktime_t, as ktime_t is now a s64.<br>- Replace set_task_state() with set_current_state() as the former no longer<br>  exists.<br>- Use cpus_ptr instead of cpus_allowed (see upstream commit<br>  3bd3706251ee8ab67e69d9340ac2abdca217e733).<br>- Rework how we handle namespace clutter from debug_trace.h. Instead of using a<br>  macro to control this, stop including debug_trace.h from preempt.h and<br>  instead include the new file debug_trace_common.h which provides<br>  sched_trace_log_message() for both debug_trace.h and preempt.h.<br>- Fix a stack frame overflow issue in pfair_activate_plugin().<br>- Use correct, lower case in sysrq help for LITMUS's "x" and "y" commands.<br>- Squash most of the bug and typo fix commits.<br><br>Variants of this rebase onto Linux 5.4 (5.4-rc7 and 5.4.108) have been in<br>testing at UNC for over two years, have been used in several publications, and<br>have passed multiple artifact evaluations. This release makes no userspace API<br>changes, so liblitmus and feather-trace-tools do not require updating.<br><br>Please test and let me know if you encounter any problems. I would like to<br>begin the process of officially releasing this by the end of the year.<br><br>(For those new to this list, the last release candidate was made on Nov 14th,<br>2022: <a href="https://lists.litmus-rt.org/pipermail/litmus-dev/2021/001717.html">https://lists.litmus-rt.org/pipermail/litmus-dev/2021/001717.html</a>. This<br>release updates that rebase and adds a couple minor fixes to LITMUS's<br>sysrq-related code. Note that this rebase does not include any functional <br>changes to GSN-EDF's job numbering behavior, even though the current behavior <br>could be considered questionable. See initial rebase discussion for more info:<br><a href="https://lists.litmus-rt.org/pipermail/litmus-dev/2020/001711.html">https://lists.litmus-rt.org/pipermail/litmus-dev/2020/001711.html</a>.)<div><br></div>Best regards,<br><br><div>Joshua Bakita</div><div>PhD Student | Real-Time Systems | UNC Chapel Hill</div></div>