[LITMUS^RT] Announcing Linux-5.4-Based LITMUS^RT Release Candidate 2

Joshua Bakita jbakita at cs.unc.edu
Wed Nov 16 23:44:51 CET 2022


Hello LITMUS^RT developers and users,

I'm excited to announce that the second release candidate of LITMUS^RT
rebased
on Linux 5.4 is now available for testing! The sources are available in the
linux-5.4-litmus branch on https://github.com/JoshuaJB/litmus-rt.git.

Changes made during the rebase from Linux 4.9.30 to 5.4.224:
- Make miscellaneous whitespace cleanup and include fixes.
- Correct for minor changes in type and function names.
- Switch from sys_kill() to do_send_sig_info().
- Add _HARD postfix to relevant LITMUS^RT hrtimers for PREEMPT-RT support.
- Add a dummy balance function to kernel/sched/litmus.c.
- set_curr_task() was renamed set_next_task() upstream. Reflect here.
- Adjust pick_next_task_litmus() to use rq->curr instead of prev since we no
  longer get a valid version of prev. Our logic cannot be moved to the new
  balance function, as that's not called when CONFIG_SMP is disabled.
- Remove put_prev_task() call from pick_next_task_litmus(), as this is now
  automatically invoked by our caller. This implies that put_prev_task() is
now
  called more often than before, but there's nothing that can be done about
  that without adding special-case logic in kernel/sched/core.c.
- Remove lockdep_unpin_lock() and lockdep_repin_lock() invocations from
  litmus_pick_next_task() as that function is no longer passed a non-NULL
  rf->cookie. See earlier note about why we can't move the logic of this
  function to balance_litmus(). These calls are merely annotations which
  validate lock state, and are not strictly necessary (see
  doc/Documention/locking/lockdep-design.txt).
- Adjust for restructure of smp_reschedule_interrupt().
- set_next_task() in every scheduling class now takes a `first` parameter.
This
  seems to be safe to ignore in SCHED_LITMUS.
- The mutex owner field is now atomic (see upstream commit
  3ca0ff571b092ee4d807f1168caa428d95b0173b), so we no longer need to handle
the
  preemption case and check for is_realtime().
- Conditionally set the next-lowest-priority scheduling class in
SCHED_LITMUS
  as stop_sched_class is now only used if CONFIG_SMP.
- Stop requesting the tv64 field from ktime_t, as ktime_t is now a s64.
- Replace set_task_state() with set_current_state() as the former no longer
  exists.
- Use cpus_ptr instead of cpus_allowed (see upstream commit
  3bd3706251ee8ab67e69d9340ac2abdca217e733).
- Rework how we handle namespace clutter from debug_trace.h. Instead of
using a
  macro to control this, stop including debug_trace.h from preempt.h and
  instead include the new file debug_trace_common.h which provides
  sched_trace_log_message() for both debug_trace.h and preempt.h.
- Fix a stack frame overflow issue in pfair_activate_plugin().
- Use correct, lower case in sysrq help for LITMUS's "x" and "y" commands.
- Squash most of the bug and typo fix commits.

Variants of this rebase onto Linux 5.4 (5.4-rc7 and 5.4.108) have been in
testing at UNC for over two years, have been used in several publications,
and
have passed multiple artifact evaluations. This release makes no userspace
API
changes, so liblitmus and feather-trace-tools do not require updating.

Please test and let me know if you encounter any problems. I would like to
begin the process of officially releasing this by the end of the year.

(For those new to this list, the last release candidate was made on Nov
14th,
2022: https://lists.litmus-rt.org/pipermail/litmus-dev/2021/001717.html.
This
release updates that rebase and adds a couple minor fixes to LITMUS's
sysrq-related code. Note that this rebase does not include any functional
changes to GSN-EDF's job numbering behavior, even though the current
behavior
could be considered questionable. See initial rebase discussion for more
info:
https://lists.litmus-rt.org/pipermail/litmus-dev/2020/001711.html.)

Best regards,

Joshua Bakita
PhD Student | Real-Time Systems | UNC Chapel Hill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20221116/c9ffbc8a/attachment.html>


More information about the litmus-dev mailing list