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

[Valentin Stangaciu]

Hello everyone,

I can confirm that this RC-2 of Litmus RT works fine on ArchLinuxARM for 
Raspberry PI. I used the latest version of ArchLinuxARM available.

All of our applications work fine with this new upgrade. This is a great 
help because now we can move to more recent versions of the OS in our 
studies.

Thank you for sharing this updated version of the kernel !

Best regards,

------------------------------------------------------------------------

           Dr. Eng. *Valentin STANGACIU*
           Lecturer
           System Administrator of the Department

Politehnica University of Timisoara
Computer & Software Engineering Department
Digital Signal Processing Laboratories

2, Vasile Parvan Bv., 300223, Timisoara, Romania
+40 256 403271 / +40 256 403214 / +40 722 896872
valentin.stangaciu at cs.upt.ro <mailto:valentin.stangaciu at cs.upt.ro>
http://dsplabs.cs.upt.ro/~valys <http://dsplabs.cs.upt.ro/~valys>

------------------------------------------------------------------------



On 17.11.2022 00:44, Joshua Bakita wrote:
> 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
>
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20221209/b216c4fe/attachment-0001.html>