Dates and Events:
|
OSADL Articles:
2023-11-12 12:00
Open Source License Obligations Checklists even better now
Import the checklists to other tools, create context diffs and merged lists
2022-07-11 12:00
Call for participation in phase #4 of Open Source OPC UA open62541 support project
Letter of Intent fulfills wish list from recent survey
2022-01-13 12:00
Phase #3 of OSADL project on OPC UA PubSub over TSN successfully completed
Another important milestone on the way to interoperable Open Source real-time Ethernet has been reached
2021-02-09 12:00
Open Source OPC UA PubSub over TSN project phase #3 launched
Letter of Intent with call for participation is now available
2017-09-12 12:00
OSADL project to create Open Source license checklists
Facilitate Open Source software delivery |
Hannover Messe 2024
HOT - Heidelberg OSADL Talks 2024 (online event)
OSADL Networking Day 2024 in Heidelberg, Germany
Real Time Linux Workshops
1999 - 2000 - 2001 - 2002 - 2003 - 2004 - 2005 - 2006 - 2007 - 2008 - 2009 - 2010 - 2011 - 2012 - 2013 - 2014 - 2015 - 2017
16th Real Time Linux Workshop, October 12 to 13, 2014 at the CCD Congress Center Dusseldorf collocated with LinuxCon Europe in Dusseldorf, Germany
Announcement - Call for participation (ASCII) - Hotels - Directions - Agenda - Paper Abstracts - Presentations - Registration - Abstract Submission - Sponsors - Gallery
Release of another "Latest Stable" Linux real-time kernel - why did it take so long?
Carsten Emde, Open Source Automation Development Lab (OSADL) eG
OSADL's "Latest Stable" Linux real-time kernel was released only recently. The last but one release has happened years ago, and the question arises why it took so long this time.
The release process of declaring an RT patched kernel as "Latest Stable" is as follows: All continuously monitored systems of the OSADL QA Farm that run a particular release candidate must be stable and no recorded variable must show any regression when compared to the preceding "Latest Stable" kernel version. Although straight forward at first glance, this process created a number of unexpected challenges that will be outlined in this paper.
The main reason why run-time stability was so difficult to reach was related to the advent of ARM-based platforms that required a vendor kernel to run. Such vendor kernels generally were difficult to equip with real-time capabilities, since the PREEMPT_RT patch either could not be applied at all, or the vendor additions to the kernel prevented them from running in a stable manner. This situation only improved in December 2013 when important ARM platforms such as AM335x and i.MX6 were able to run mainline Linux with very few off-tree patches.
The observed regressions were difficult to fight, since they depend much more than stability on user-space applications. User-space, however, depends on the update policy of the particular distro, and it was part of the QA Farm strategy, at least in a number of systems, to install new versions of user-space program when they become available. This policy was chosen deliberately to accept or reject compatibility of OSADL's "Latest Stable" Linux real-time kernel with particular update levels of the distros under test.
In conclusion, the process to reach a "Latest Stable" PREEMPT_RT real-time kernel is tedious and cumbersome; however, there is no alternative to it - at least not, if the kernel is intended to be used in the industry and as a base version of kernels that will undergo safety certification.
