The document discusses selecting and managing Linux kernel versions, including mainline, stable, and long-term kernels. It notes mainline kernels are released every 2-3 months with new features, while stable kernels receive only bug and security fixes. Long-term kernels provide long-term support with backported fixes for older releases. The document recommends using a release version over rolling versions for stability and outlines practices for monitoring kernels and addressing regressions.
Design, Build,and Maintain the Embedded Linux PlatformSZ Lin
Using open source software to build an embedded Linux platform from scratch.
Building an embedded Linux platform is like a puzzle; placing the suitable software components in the right positions will constitute an optimal platform. However, selecting suitable components is difficult since it depends on different application scenarios. The essential components of an embedded Linux platform include the bootloader, Linux kernel, toolchain, root filesystem; it also needs the tools for image generation, upgrades, and testing. There are abundant resources in the Linux ecosystem with these components and tools; however, selecting the suitable modules and tools is still a key challenge for system designers.
It's a pivotal challenge to update the software in embedded systems due to many restrictions such as unreliable network and power supply, limited bandwidth, harsh environment, etc. This slide aims to provide the background knowledge and the open source tool to achieve the software update in embedded systems.
Manage kernel vulnerabilities in the software development lifecycleSZ Lin
This slide deck aims to introduce the methodology in managing the Linux kernel vulnerabilities in the software development lifecycle (SLDC) to reduce the maintenance effort.
Introduction to Civil Infrastructure PlatformSZ Lin
CIP is target to establish an open source base layer of industrial grade software to enable the use and implementation of software. This slide will introduce the current status and road map in CIP
Using open source software to build an industrial grade embedded linux platfo...SZ Lin
Building an embedded Linux platform is like a puzzle; placing the suitable software components in the right positions will constitute an optimal platform. However, selecting suitable components is difficult since it depends on different application scenarios. The essential components of an embedded Linux platform include the bootloader, Linux kernel, toolchain, root filesystem; it also needs the tools for image generation, upgrades, and testing. There are abundant resources in the Linux ecosystem with these components and tools; however, selecting the suitable modules and tools is still a key challenge for system designers.
Long-term Maintenance Model of Embedded Industrial Linux DistributionSZ Lin
To introduce a robust, secure and reliable platform for the industrial environments is a key challenge; moreover, the platform needs to survive for a long time (more than 10+ years). There are many good solutions aiming to meet these requirements, such as LTSI (Long Term Support Initiative) and CIP (Civil Infrastructure Platform). However, it still needs a high amount of maintenance and development costs in handling SoC/ hardware board in-house patch, non-upstream driver and keep source code consistent with different SoC and platform afterwards.
In this presentation, SZ Lin will introduce how to operate long-term maintenance model of embedded industrial Linux distribution. In addition, he will also address the building, deploying and testing architecture and workflow for producing a robust, secure and reliable platform.
Design, Build,and Maintain the Embedded Linux PlatformSZ Lin
Using open source software to build an embedded Linux platform from scratch.
Building an embedded Linux platform is like a puzzle; placing the suitable software components in the right positions will constitute an optimal platform. However, selecting suitable components is difficult since it depends on different application scenarios. The essential components of an embedded Linux platform include the bootloader, Linux kernel, toolchain, root filesystem; it also needs the tools for image generation, upgrades, and testing. There are abundant resources in the Linux ecosystem with these components and tools; however, selecting the suitable modules and tools is still a key challenge for system designers.
It's a pivotal challenge to update the software in embedded systems due to many restrictions such as unreliable network and power supply, limited bandwidth, harsh environment, etc. This slide aims to provide the background knowledge and the open source tool to achieve the software update in embedded systems.
Manage kernel vulnerabilities in the software development lifecycleSZ Lin
This slide deck aims to introduce the methodology in managing the Linux kernel vulnerabilities in the software development lifecycle (SLDC) to reduce the maintenance effort.
Introduction to Civil Infrastructure PlatformSZ Lin
CIP is target to establish an open source base layer of industrial grade software to enable the use and implementation of software. This slide will introduce the current status and road map in CIP
Using open source software to build an industrial grade embedded linux platfo...SZ Lin
Building an embedded Linux platform is like a puzzle; placing the suitable software components in the right positions will constitute an optimal platform. However, selecting suitable components is difficult since it depends on different application scenarios. The essential components of an embedded Linux platform include the bootloader, Linux kernel, toolchain, root filesystem; it also needs the tools for image generation, upgrades, and testing. There are abundant resources in the Linux ecosystem with these components and tools; however, selecting the suitable modules and tools is still a key challenge for system designers.
Long-term Maintenance Model of Embedded Industrial Linux DistributionSZ Lin
To introduce a robust, secure and reliable platform for the industrial environments is a key challenge; moreover, the platform needs to survive for a long time (more than 10+ years). There are many good solutions aiming to meet these requirements, such as LTSI (Long Term Support Initiative) and CIP (Civil Infrastructure Platform). However, it still needs a high amount of maintenance and development costs in handling SoC/ hardware board in-house patch, non-upstream driver and keep source code consistent with different SoC and platform afterwards.
In this presentation, SZ Lin will introduce how to operate long-term maintenance model of embedded industrial Linux distribution. In addition, he will also address the building, deploying and testing architecture and workflow for producing a robust, secure and reliable platform.
Building, deploying and testing an industrial linux platform @ Open source su...SZ Lin
To introduce a robust, secure and reliable platform for the industrial environments is a key challenge. Therefore, running with the industrial-grade Linux distribution to fulfill the requirements mentioned above is imperative. The Linux distribution includes the Linux kernel and user space. Based on this testing design, the distribution will be built, deployed and tested in the device under automatic test by using continuous integration development practice to withstand the harsh industrial environments. In this presentation, SZ Lin will introduce how the industrial-grade Linux distribution is built, deployed and tested without human intervention, and review the test scope in both Linux kernel and user space. In addition, he will also address the design architecture of 24/7 long-term automated testing in all device under test with each release of new update.
2009-09-24 Get the Hype on System z Webinar with IBM, Current & Future Linux ...Shawn Wells
Joint webinar series with Hans Picht (Linux on System z Lead, IBM). Covered recent release of Red Hat Enterprise Linux 5.4, which had the inclusion of Named Saved Segments (NSS), updated fiber channel, and rebasing of s390utils. Stepped through roadmap for RHEL on System z and gave update on CMM2 development activities.
This presentation by Roman Stratiienko (Software Engineer, Consultant, GlobalLogic) and Stanislav Goncharov (Senior Software Engineer, Consultant, GlobalLogic) was delivered at GlobalLogic Kharkiv Embedded TechTalk #5 on November 22, 2019.
Speakers shared their experience and results on the challenge started last year to make porting of cutting edge Android 10 to low-cost Orange Pi Plus 2E platform. They made it open source and available for every embedded s/w enthusiast based on AOSP project and Linux kernel upstream.
Event materials: https://www.globallogic.com/ua/events/kharkiv-embedded-techtalk-5/
Kernel Recipes 2013 - ARM support in the Linux kernelAnne Nicolas
Over the past two years, the support of the platforms based on ARM processor in the Linux kernel has evolved considerably. Between the use of the Device Tree, moving drivers in many features like clock management or multiplexing of pines, the platform mechanism, the changes have been numerous.
Through the experience of the speaker about the addition to the core support for ARM Marvell Armada 370/XP processors, this intervention will provide an overview of these changes in order to better understand the new organization of the code for ARM architecture in the kernel.
This talk is intended to be useful both for developers who want to add support for a new ARM processor in the kernel, but also to those wishing to understand the ARM code for porting Linux to a new card, or just the curious one.
Kernel Recipes 2019 - Driving the industry toward upstream firstAnne Nicolas
Wanting to avoid the Android experience, Google developers always aimed to make their Chrome OS Linux kernels as close to mainline as possible. However, when Chromebooks were first created, Google was left with no choice, the mainline kernel, in some subsystems, still did not have all the functionalities needed by Chromebooks. Hence, similarly to Android, Chrome OS had to develop their own out-of-tree code for the kernel and maintain that for a few different kernel versions.
Luckily, over the last few years a strong and consistent effort has been happening to bring Chromebook devices closer to mainline. It has led to significant improvements that now make it possible to run mainline on Chrome OS devices. And not only Chromebooks, as these significant strides are also improving Arm-based SOCs and other key components of the rich Chromebook hardware ecosystem. In this talk, we will look at how and why upstream support for Chromebooks improved, the current status of various models, and what we expect in the future.
Enric Balletbò i Serra
2008-07-30 IBM Teach the Teacher (IBM T3), Red Hat Update for System zShawn Wells
Red Hat Update at IBM Teach the Teacher (IBM T3) Conference in Endicott, NY. Covering Red Hat's community development model, System z announcements, SELinux, SCAP, and Red Hat Network Satellite for Systems Management.
Quieting noisy neighbor with Intel® Resource Director TechnologyMichelle Holley
A typical computer server on the cloud hosted multiple VMs. Each VM hosted an independent application. The operation of a mixture of applications in cloud requires proper resource management and it's critical to QoS, this session is to study the impact of different neighbors on an application’s performance and to show how Intel® RDT can help to detect and mitigate a noisy-neighbor situation.
About the authors: Sunil is senior cloud performance engineer at Intel working on cloud performance and optimization for Oracle cloud. Prior to this he worked on service assurance and orchestration products for Openstack cloud. Sunil has 10+ years of experience working on different software products for server management. He holds Masters in Computer Science from IIT Chicago.
Khun Ban is a cloud performance engineer manager leading a team to optimize cloud performance and TCO. He has over twenty years of enterprise software development experience. His current focus is on providing customer with best cloud experience. He received his B.S. degree in Computer Science and Engineering from the University of Washington in 1995.
Building, deploying and testing an industrial linux platform @ Open source su...SZ Lin
To introduce a robust, secure and reliable platform for the industrial environments is a key challenge. Therefore, running with the industrial-grade Linux distribution to fulfill the requirements mentioned above is imperative. The Linux distribution includes the Linux kernel and user space. Based on this testing design, the distribution will be built, deployed and tested in the device under automatic test by using continuous integration development practice to withstand the harsh industrial environments. In this presentation, SZ Lin will introduce how the industrial-grade Linux distribution is built, deployed and tested without human intervention, and review the test scope in both Linux kernel and user space. In addition, he will also address the design architecture of 24/7 long-term automated testing in all device under test with each release of new update.
2009-09-24 Get the Hype on System z Webinar with IBM, Current & Future Linux ...Shawn Wells
Joint webinar series with Hans Picht (Linux on System z Lead, IBM). Covered recent release of Red Hat Enterprise Linux 5.4, which had the inclusion of Named Saved Segments (NSS), updated fiber channel, and rebasing of s390utils. Stepped through roadmap for RHEL on System z and gave update on CMM2 development activities.
This presentation by Roman Stratiienko (Software Engineer, Consultant, GlobalLogic) and Stanislav Goncharov (Senior Software Engineer, Consultant, GlobalLogic) was delivered at GlobalLogic Kharkiv Embedded TechTalk #5 on November 22, 2019.
Speakers shared their experience and results on the challenge started last year to make porting of cutting edge Android 10 to low-cost Orange Pi Plus 2E platform. They made it open source and available for every embedded s/w enthusiast based on AOSP project and Linux kernel upstream.
Event materials: https://www.globallogic.com/ua/events/kharkiv-embedded-techtalk-5/
Kernel Recipes 2013 - ARM support in the Linux kernelAnne Nicolas
Over the past two years, the support of the platforms based on ARM processor in the Linux kernel has evolved considerably. Between the use of the Device Tree, moving drivers in many features like clock management or multiplexing of pines, the platform mechanism, the changes have been numerous.
Through the experience of the speaker about the addition to the core support for ARM Marvell Armada 370/XP processors, this intervention will provide an overview of these changes in order to better understand the new organization of the code for ARM architecture in the kernel.
This talk is intended to be useful both for developers who want to add support for a new ARM processor in the kernel, but also to those wishing to understand the ARM code for porting Linux to a new card, or just the curious one.
Kernel Recipes 2019 - Driving the industry toward upstream firstAnne Nicolas
Wanting to avoid the Android experience, Google developers always aimed to make their Chrome OS Linux kernels as close to mainline as possible. However, when Chromebooks were first created, Google was left with no choice, the mainline kernel, in some subsystems, still did not have all the functionalities needed by Chromebooks. Hence, similarly to Android, Chrome OS had to develop their own out-of-tree code for the kernel and maintain that for a few different kernel versions.
Luckily, over the last few years a strong and consistent effort has been happening to bring Chromebook devices closer to mainline. It has led to significant improvements that now make it possible to run mainline on Chrome OS devices. And not only Chromebooks, as these significant strides are also improving Arm-based SOCs and other key components of the rich Chromebook hardware ecosystem. In this talk, we will look at how and why upstream support for Chromebooks improved, the current status of various models, and what we expect in the future.
Enric Balletbò i Serra
2008-07-30 IBM Teach the Teacher (IBM T3), Red Hat Update for System zShawn Wells
Red Hat Update at IBM Teach the Teacher (IBM T3) Conference in Endicott, NY. Covering Red Hat's community development model, System z announcements, SELinux, SCAP, and Red Hat Network Satellite for Systems Management.
Quieting noisy neighbor with Intel® Resource Director TechnologyMichelle Holley
A typical computer server on the cloud hosted multiple VMs. Each VM hosted an independent application. The operation of a mixture of applications in cloud requires proper resource management and it's critical to QoS, this session is to study the impact of different neighbors on an application’s performance and to show how Intel® RDT can help to detect and mitigate a noisy-neighbor situation.
About the authors: Sunil is senior cloud performance engineer at Intel working on cloud performance and optimization for Oracle cloud. Prior to this he worked on service assurance and orchestration products for Openstack cloud. Sunil has 10+ years of experience working on different software products for server management. He holds Masters in Computer Science from IIT Chicago.
Khun Ban is a cloud performance engineer manager leading a team to optimize cloud performance and TCO. He has over twenty years of enterprise software development experience. His current focus is on providing customer with best cloud experience. He received his B.S. degree in Computer Science and Engineering from the University of Washington in 1995.
CentOS Virt SIG - Community virtualization packages on an immutable coreThe Linux Foundation
CentOS is a "distribution" with a rather unique description: it is a free (gratis) clone of a commercially-supported "distribution" with all the branding removed. Being enterprise-grade distribution means solid and well-tested; but it also means not having the latest functionality. It also means having a small enough feature set to provide commercial support in a viable manner: and that typically means choosing one technology and sticking with it.
But what if you wanted your entire system to be solid, and well-tested, but want the latest features for one particular package or program? Or what if you really wanted an enterprise system, but wanted to use one of the alternate technoligies that were not selected?
This is where CentOS SIGs come in. The new CentOS is still at its core a clone of an upstream enterprise distribution. But having had success with the Xen4CentOS project, which provided a version of Xen to run on CentOS 6, they have now generalized the process.
This talk will talk about CentOS SIGs: the vision, the structure, what SIGs are available. We will compare and contrast them to other community distro development models like Fedora, OpenSuSE, Debian, Ubuntu, and so forth. We will also share lessons from the CentOS Virt SIG, in which a number of virtualisation and related technologies such as Xen, oVirt, Docker and others collaborate.
Kernel Recipes 2016 - The kernel reportAnne Nicolas
The Linux kernel is at the core of any Linux system; the performance and capabilities of the kernel will, in the end, place an upper bound on what he system as a whole can do. This talk will review recent events in the kernel development community, discuss the current state of the kernel and the challenges it faces, and look forward to how the kernel may address those challenges. Attendees of any technical ability should gain a better understanding of how the kernel got to its current state and what can be expected in the near future.
Jonathan Corbet, LWN.net
Presentation delivered at LinuxCon China 2017 by Greg Kroah-Hartman.
The Linux kernel is the largest collaborative software development projects ever. This talk will discuss exactly how Linux is developed, how fast it is happening, who is doing the work, and how we all stay sane keeping up with it. It will discuss the development model used, and how it differs from almost all "traditional" models of software development.
With the introduction of CentOS Stream, it is now possible to contribute to CentOS directly. This talk will go over Facebook's experience working with CentOS (the distro, the project, the community), growing from consumer, to contributor, to founding member of the new Hyperscale SIG, which strives to facilitate collaboration around large-scale CentOS deployments.
Linux Kernel Multmedia Subsystem maintainer and Samsung OSG team member Mauro Chehab talks about how the multimedia subsystem is architected and contributed to in the Linux Kernel.
Kernel Recipes 2015 - Hardened kernels for everyoneAnne Nicolas
Grsecurity is a Linux kernel hardening patch. The PaX patchset it includes pioneered some security features like ASLR which where later included in basically every operating system. But the patch itself is still standalone (not included mainline), so most Linux users don’t benefit its security features.
A lot of people only use binary distribution kernels, and this talk will present some challenges found when trying to provide a distribution kernel with Grsecurity included.
I’ll first quickly present the grsecurity patch, then the attempt to include it in the Debian distribution kernel as a featureset. Finally there will be some pointers on how to provide hardened kernels easily for as many people as possible.
Yves-Alexis Perez, ANSSI
Slides of the talk I did at LinuxWochen Wien 2014.
This talk will give you a quick introduction to Linux kernel development. During the talk we will explore some options of contribution, including random configurations, stable-testing, RC-testing and actual coding! By the end of the talk we will post a basic patch to the developers as well.
2008-11-13 CAVMEN RHEL for System z Deep DiveShawn Wells
Audience was technical Linux on System z practitioners. Steps through the Linux on System z development process, what is included in RHEL for System z (now + future), provisioning and patch management, and broad security updates (SELinux, Auditing, Crypto).
The talk is a status report for the latest release and development projects. It will cover the new features and important bug fixes (if any) in 4.7. It will also provide insight on what’s in the queue for the next major release. Retrospective on the release process will also be part of talk.
Similar to Select, manage, and backport the long term stable kernels (20)
Industry Insights Common Pitfalls and Key Considerations in Using Software Bi...SZ Lin
Modern regulations and cybersecurity standards globally now require a Software Bill of Materials (SBOM) with specific details. As a result, many companies are adopting SBOMs. Yet, compliance isn't merely technical. It involves process, inter-departmental, and supply chain communication challenges. This session explores these SBOM challenges and provides insights for effective use. Many perceive the SBOM simply as an inventory, neglecting its significance in software management, component tracking, vulnerability assessments, and compliance assurance. While automation streamlines processes, an over-reliance can miss software intricacies; thus, manual reviews remain indispensable. Assuming an SBOM alone ensures a secure software supply chain is a misconception. Though pivotal in risk identification, SBOMs form just a facet of an overarching security strategy, demanding consistent updates to counteract emerging threats. By sidestepping common missteps and adopting best practices, SBOMs can evolve from simple documentation to indispensable tools for software governance and safeguarding.
OpenChain, the ISO standard, defines effective open source compliance. This slide deck aims to let people get familiar with OpenChain specification from scratch.
OpenChain - The Industry Standard for Open Source ComplianceSZ Lin
OpenChain is a legal compliance process and standard for the implementation of open source software in the enterprise supply chain. It enables the upstream and downstream of the software supply to follow and share the open source compliance obligations accordingly; moreover, it can also help the enterprises to collaborate with the open source communities positively.
Take a step forward from user to maintainer or developer in open source secur...SZ Lin
There are a variety of high-quality open source security-related tools available in penetration testing tools, forensics tools, hardening tools, fuzz tools, and network monitoring tools. These tools could be used freely; however, we might face some issues while using it. Therefore, it is essential to have the ability to maintain or develop these tools. In this slide, SZ Lin introduces Security Tools Packaging Team in Debian; this team aims to maintain collaboratively many security tools and merge back tools packaged by security-oriented Debian derivatives (e.g., Kali). Also, SZ shares the experience in discussing and collaborating with open source maintainers and developers in open source security-related tools.
Welcome to WIPAC Monthly the magazine brought to you by the LinkedIn Group Water Industry Process Automation & Control.
In this month's edition, along with this month's industry news to celebrate the 13 years since the group was created we have articles including
A case study of the used of Advanced Process Control at the Wastewater Treatment works at Lleida in Spain
A look back on an article on smart wastewater networks in order to see how the industry has measured up in the interim around the adoption of Digital Transformation in the Water Industry.
Hierarchical Digital Twin of a Naval Power SystemKerry Sado
A hierarchical digital twin of a Naval DC power system has been developed and experimentally verified. Similar to other state-of-the-art digital twins, this technology creates a digital replica of the physical system executed in real-time or faster, which can modify hardware controls. However, its advantage stems from distributing computational efforts by utilizing a hierarchical structure composed of lower-level digital twin blocks and a higher-level system digital twin. Each digital twin block is associated with a physical subsystem of the hardware and communicates with a singular system digital twin, which creates a system-level response. By extracting information from each level of the hierarchy, power system controls of the hardware were reconfigured autonomously. This hierarchical digital twin development offers several advantages over other digital twins, particularly in the field of naval power systems. The hierarchical structure allows for greater computational efficiency and scalability while the ability to autonomously reconfigure hardware controls offers increased flexibility and responsiveness. The hierarchical decomposition and models utilized were well aligned with the physical twin, as indicated by the maximum deviations between the developed digital twin hierarchy and the hardware.
Hybrid optimization of pumped hydro system and solar- Engr. Abdul-Azeez.pdffxintegritypublishin
Advancements in technology unveil a myriad of electrical and electronic breakthroughs geared towards efficiently harnessing limited resources to meet human energy demands. The optimization of hybrid solar PV panels and pumped hydro energy supply systems plays a pivotal role in utilizing natural resources effectively. This initiative not only benefits humanity but also fosters environmental sustainability. The study investigated the design optimization of these hybrid systems, focusing on understanding solar radiation patterns, identifying geographical influences on solar radiation, formulating a mathematical model for system optimization, and determining the optimal configuration of PV panels and pumped hydro storage. Through a comparative analysis approach and eight weeks of data collection, the study addressed key research questions related to solar radiation patterns and optimal system design. The findings highlighted regions with heightened solar radiation levels, showcasing substantial potential for power generation and emphasizing the system's efficiency. Optimizing system design significantly boosted power generation, promoted renewable energy utilization, and enhanced energy storage capacity. The study underscored the benefits of optimizing hybrid solar PV panels and pumped hydro energy supply systems for sustainable energy usage. Optimizing the design of solar PV panels and pumped hydro energy supply systems as examined across diverse climatic conditions in a developing country, not only enhances power generation but also improves the integration of renewable energy sources and boosts energy storage capacities, particularly beneficial for less economically prosperous regions. Additionally, the study provides valuable insights for advancing energy research in economically viable areas. Recommendations included conducting site-specific assessments, utilizing advanced modeling tools, implementing regular maintenance protocols, and enhancing communication among system components.
Industrial Training at Shahjalal Fertilizer Company Limited (SFCL)MdTanvirMahtab2
This presentation is about the working procedure of Shahjalal Fertilizer Company Limited (SFCL). A Govt. owned Company of Bangladesh Chemical Industries Corporation under Ministry of Industries.
Cosmetic shop management system project report.pdfKamal Acharya
Buying new cosmetic products is difficult. It can even be scary for those who have sensitive skin and are prone to skin trouble. The information needed to alleviate this problem is on the back of each product, but it's thought to interpret those ingredient lists unless you have a background in chemistry.
Instead of buying and hoping for the best, we can use data science to help us predict which products may be good fits for us. It includes various function programs to do the above mentioned tasks.
Data file handling has been effectively used in the program.
The automated cosmetic shop management system should deal with the automation of general workflow and administration process of the shop. The main processes of the system focus on customer's request where the system is able to search the most appropriate products and deliver it to the customers. It should help the employees to quickly identify the list of cosmetic product that have reached the minimum quantity and also keep a track of expired date for each cosmetic product. It should help the employees to find the rack number in which the product is placed.It is also Faster and more efficient way.
Select, manage, and backport the long term stable kernels
1. Select, Manage, and Backport the
LongTerm Stable Kernels
林上智 (SZ LIN) szlin@debian.org
蔡鎮宇 wens@csie.org
1
Date: 2021/7/31
2. 2
Disclaimer
• The information contained in the slide deck
represents the views and opinions of the
presenters and does not necessarily represent
the views or opinions of presenters’ past,
current, and future employers.
3. > 80 %
> 75 % 100 %
> 95 %
img src: https://kernel.org
src: https://www.linuxfoundation.org/about/
of the top one
million domains run
with Linux
of cloud-enabled
enterprises report
using Linux as their
primary cloud
platform
of new smartphones
sold run Android,
which is based on
the Linux kernel
of the top 500
supercomputers in
the world run on
Linux
6. Mainline Kernel [1]
Mainline tree is maintained by Linus Torvalds. It's the tree where all new features are introduced
and where all the exciting new development happens. New mainline kernels are released every
2-3 months.
Mainline Kernel [1]
Mainline tree is maintained by Linus Torvalds. It's the tree where all new features are introduced
and where all the exciting new development happens. New mainline kernels are released every
2-3 months.
7. Stable Kernel [1]
After each mainline kernel is released, it is considered "stable." Any bug fixes for a stable kernel
are backported from the mainline tree and applied by a designated stable kernel maintainer.
There are usually only a few bugfix kernel releases until next mainline kernel becomes available -
- unless it is designated a "longterm maintenance kernel." Stable kernel updates are released on
as-needed basis, usually once a week.
Stable Kernel [1]
After each mainline kernel is released, it is considered "stable." Any bug fixes for a stable kernel
are backported from the mainline tree and applied by a designated stable kernel maintainer.
There are usually only a few bugfix kernel releases until next mainline kernel becomes available -
- unless it is designated a "longterm maintenance kernel." Stable kernel updates are released on
as-needed basis, usually once a week.
8. Longterm Kernel [1]
There are usually several "longterm maintenance" kernel releases provided for the purposes of
backporting bugfixes for older kernel trees. Only important bugfixes are applied to such kernels
and they don't usually see very frequent releases, especially for older trees.
Longterm Kernel [1]
There are usually several "longterm maintenance" kernel releases provided for the purposes of
backporting bugfixes for older kernel trees. Only important bugfixes are applied to such kernels
and they don't usually see very frequent releases, especially for older trees.
9. End of LTS
9
Linux Kernel Releases
Mainline
Longterm
v4.4
Longterm
6+? years
v4.5 v4.19 v5.x
EOL
v4.4.x v4.4.y v4.4.z
v4.19.a v4.19.b
img src: https://en.wikipedia.org/wiki/Linux_kernel_version_history
End of LTS
6+? years
v4.4 v4.5 v4.19
Stable
10. 27.8
60-90 Day 66,492 3,386,347
21,074
Mainline Kernel
Release Cycle
Million Lines Files Lines of New Codes
in 2019
Different Authors
10
src: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Git-Stats-EOY2019
img src: https://kernel.org
11. LTS: Long Term Stable Kernel [3]
Extend software uptime for stable kernel
• Only accept bug fixes and security fixes
img: https://www.kernel.org/category/releases.html
Retrieved 7th July
11
12. SoC Board Support Package Kernel
• Kernel version depends on SoC vendors
– Well made but not well maintained
• Contain lots of in-house patches
– Errata patches
– Specific feature patches
– …
• Different SoC might use different versions of kernel
• The lifetime is unsure
12
13. LTSI: Long Term Support Initiative [6]
• Linux Foundation collaborative project
– Based on LTS
– Add another chance to include further patches on top of LTS
– Auto Test framework
– Same lifetime with LTS (yearly release and 2 years life time)
13
14. CIP (Civil Infrastructure Platform) [7]
• Linux Foundation collaborative project
– Support kernel and core package
– Auto Test framework
– Maintenance period
• 10 years and more (10-20 years)
14
More info: CIP Kernel Team Activities to Accomplish Super Long Term Support
Embedded Linux Conference, 2020 [8]
15. Linux Kernel Source Comparison Table
Version
Maintenance
Period
(years)
Features
Latest
Version
Supported Real-
time kernel
Maintainer
SoC
BSP kernel
? Bug fixes ? N SoC vendor kernel team
LTS
kernel
2 ~ ?
• Bug fixes
• Security fixes
5.10 N Kernel.org
LTSI kernel 2 ~ ?
• Bug fixes
• Security fixes
• Specific features
• New features
4.14 N
LTSI
(Linux Foundation Projects)
CIP
kernel
10 +
• Bug fixes
• Security fixes
• Specific features
• New features
5.10 Y
CIP
(Linux Foundation Projects)
15
16. Use Release Version Instead of Rolling Version
v4.4.1
Security fixes
Security fixes
Bug fixes
Bug fixes
Upstream
rolling version
16
v4.4.2 v4.4.3
20. Supply Chain Risk Management Practices
for Federal Information Systems and
Organizations
Special Publication 800-161 [4]
SM-9: Security requirements for
externally provided components
ISA/ IEC 62443-4-1 [5] NERCCIP-010-2 [6]
Configuration Change Management and
Vulnerability Assessments
img src: https://pixabay.com/illustrations/policies-standards-compliance-4720824/
20
23. 23
Proactive Management
- Monitor the status of stable kernel by subscribing
the mailing list
• http://vger.kernel.org/vger-lists.html#stable
From Greg Kroah-Hartman <>
Subject [PATCH 5.10 000/243] 5.10.52-rc1 review
Date Mon, 19 Jul 2021 16:50:29 +0200
This is the start of the stable review cycle for the 5.10.52 release.
There are 243 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed, 21 Jul 2021 14:47:42 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.52-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 5.10.52-rc1
Dan Carpenter <dan.carpenter@oracle.com>
scsi: scsi_dh_alua: Fix signedness bug in alua_rtpg()
…
From Greg Kroah-Hartman <>
Subject [PATCH 5.10 000/243] 5.10.52-rc1 review
Date Mon, 19 Jul 2021 16:50:29 +0200
This is the start of the stable review cycle for the 5.10.52 release.
There are 243 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed, 21 Jul 2021 14:47:42 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.52-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 5.10.52-rc1
Dan Carpenter <dan.carpenter@oracle.com>
scsi: scsi_dh_alua: Fix signedness bug in alua_rtpg()
…
34. • The project shares its results with the upstream
• The project fulfills longer time maintenance and
security fixes
• The project develops their code very quickly
• The project faces difficulties to backport upstream
patches due to conflicts as time goes by
34
36. 36
Suitable changes in LongTerm Stable Kernels [10]
1. It must be obviously correct and tested.
2. It cannot be bigger than 100 lines, with context.
3. It must fix only one thing.
4. It must fix a real bug that bothers people (not a, “This could be a problem…” type thing).
5. It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang,
data corruption, a real security issue, or some “oh, that's not good” issue. In short, something critical.
6. Serious issues as reported by a user of a distribution kernel may also be considered if they fix a notable
performance or interactivity issue. As these fixes are not as obvious and have a higher risk of a subtle
regression they should only be submitted by a distribution kernel maintainer and include an addendum linking
to a bugzilla entry if it exists and additional information on the user-visible impact.
7. New device IDs and quirks are also accepted.
8. No “theoretical race condition” issues, unless an explanation of how the race can be exploited is also provided.
9. It cannot contain any “trivial” fixes in it (spelling changes, whitespace cleanups, etc).
10. It must follow the Documentation/Submitting Patches rules.
11. It or an equivalent fix must already exist in Linus' tree (upstream).
In practice, exceptions are sometimes made to rules 2, 3, 8 and 9, and we will likewise treat those as should rather than must rules.
37. 37
Option 1. To have the patch automatically included in
the stable tree, add the tag
Subject: USB: serial: digi_acceleport: fix write-wakeup deadlocks
The driver must not call tty_wakeup() while holding its private lock as
line disciplines are allowed to call back into write() from
write_wakeup(), leading to a deadlock.
Also remove the unneeded work struct that was used to defer wakeup in
order to work around a possible race in ancient times (see comment about
n_tty write_chan() in commit 14b54e3 ("USB: serial: remove
changelogs and old todo entries")).
Fixes: 1da177e ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Subject: USB: serial: digi_acceleport: fix write-wakeup deadlocks
The driver must not call tty_wakeup() while holding its private lock as
line disciplines are allowed to call back into write() from
write_wakeup(), leading to a deadlock.
Also remove the unneeded work struct that was used to defer wakeup in
order to work around a possible race in ancient times (see comment about
n_tty write_chan() in commit 14b54e3 ("USB: serial: remove
changelogs and old todo entries")).
Fixes: 1da177e ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
src: https://github.com/torvalds/linux/commit/5098e77962e7c8947f87bd8c5869c83e000a522a
Procedure for submitting patches to the -stable tree [9]
38. 38
Option 2. After the patch has been merged to Linus’
tree, send an email
to stable@vger.kernel.org containing the subject of
the patch, the commit ID, why you think it should be
applied, and what kernel version you wish it to be
applied to.
Subject: request for 4.4-stable: 08474cc1e6ea7 ("bridge: Propagate vlan
add failure to user")
From: SZ Lin (林上智) <sz.lin@xxxxxxxx>
Date: Wed, 22 Aug 2018 20:07:14 +0800
Hi Greg,
This patch is not marked for 4.4-stable, but it's already in 4.9 and 4.14
stable.
Please apply to 4.4-stable.
This patch fixed the kernel oops issue when executing bridge tool, please
see reproducible steps with kernel 4.4 in below.
# brctl addbr br0
# brctl addif br0 eth0
[ 1073.390028] device eth0 entered promiscuous mode
[ 1073.395022] cpsw 4a100000.ethernet eth0: failed to initialize vlan
filtering on this port
# brctl addif br0 eth1
[ 1092.205685] net eth1: promiscuity not disabled as the other interface is
still in promiscuity mode
[ 1092.217541] device eth1 entered promiscuous mode
[ 1092.222460] cpsw 4a100000.ethernet eth1: failed to initialize vlan
filtering on this port
# ifconfig br0 192.168.127.253 netmask 255.255.254.0
[ 1112.412740] br0: port 1(eth0) entered forwarding state
[ 1112.417975] br0: port 1(eth0) entered forwarding state
...
Subject: request for 4.4-stable: 08474cc1e6ea7 ("bridge: Propagate vlan
add failure to user")
From: SZ Lin (林上智) <sz.lin@xxxxxxxx>
Date: Wed, 22 Aug 2018 20:07:14 +0800
Hi Greg,
This patch is not marked for 4.4-stable, but it's already in 4.9 and 4.14
stable.
Please apply to 4.4-stable.
This patch fixed the kernel oops issue when executing bridge tool, please
see reproducible steps with kernel 4.4 in below.
# brctl addbr br0
# brctl addif br0 eth0
[ 1073.390028] device eth0 entered promiscuous mode
[ 1073.395022] cpsw 4a100000.ethernet eth0: failed to initialize vlan
filtering on this port
# brctl addif br0 eth1
[ 1092.205685] net eth1: promiscuity not disabled as the other interface is
still in promiscuity mode
[ 1092.217541] device eth1 entered promiscuous mode
[ 1092.222460] cpsw 4a100000.ethernet eth1: failed to initialize vlan
filtering on this port
# ifconfig br0 192.168.127.253 netmask 255.255.254.0
[ 1112.412740] br0: port 1(eth0) entered forwarding state
[ 1112.417975] br0: port 1(eth0) entered forwarding state
...
39. Subject: [PATCH 4.4 1/3] ovl: rename is_merge to is_lowest
From: SZ Lin (林上智) <sz.lin@xxxxxxxx>
Date: Wed, 22 Aug 2018 20:07:14 +0800
From: Miklos Szeredi
commit 56656e960b555cb98bc414382566dcb59aae99a2 upstream
The 'is_merge' is an historical naming from when only a single lower layer
could exist. With the introduction of multiple lower layers the meaning of
this flag was changed to mean only the "lowest layer" (while all lower
layers were being merged).
So now 'is_merge' is inaccurate and hence renaming to 'is_lowest'
Signed-off-by: Miklos Szeredi
Signed-off-by: SZ Lin (林上智)
...
Subject: [PATCH 4.4 1/3] ovl: rename is_merge to is_lowest
From: SZ Lin (林上智) <sz.lin@xxxxxxxx>
Date: Wed, 22 Aug 2018 20:07:14 +0800
From: Miklos Szeredi
commit 56656e960b555cb98bc414382566dcb59aae99a2 upstream
The 'is_merge' is an historical naming from when only a single lower layer
could exist. With the introduction of multiple lower layers the meaning of
this flag was changed to mean only the "lowest layer" (while all lower
layers were being merged).
So now 'is_merge' is inaccurate and hence renaming to 'is_lowest'
Signed-off-by: Miklos Szeredi
Signed-off-by: SZ Lin (林上智)
...
39
Option 3. Send the patch, after verifying that it follows
the above rules, to stable@vger.kernel.org. You must
note the upstream commit ID in the changelog of your
submission, as well as the kernel version you wish it to
be applied to.
40. 40
Option 1 is strongly preferred, is the easiest and most common. Option 2 and Option 3 are
more useful if the patch isn’t deemed worthy at the time it is applied to a public git tree
(for instance, because it deserves more regression testing first). Option 3 is especially
useful if the patch needs some special handling to apply to an older kernel (e.g., if API’s
have changed in the meantime).
Note that for Option 3, if the patch deviates from the original upstream patch (for example
because it had to be backported) this must be very clearly documented and justified in the
patch description. [9]
note: another entry point of patch is AUTOSEL bot, which is a neural network for finding fixes [11].
41. 41
commit d733f7542ad47cf73e033c90cf55158587e1d060 upstream.
If an emac node has a phy-handle property that points to something
which is not a phy, then a segmentation fault will occur when the
interface is brought up. This is because while phy_connect() will
return ERR_PTR() on failure, of_phy_connect() will return NULL.
The common error check uses IS_ERR(), and so missed when
of_phy_connect() fails. The NULL pointer is then dereferenced.
Also, the common error message referenced slave->data->phy_id,
which would be empty in the case of phy-handle. Instead, use the
name of the device_node as a useful identifier. And in the phy_id
case add the error code for completeness.
Fixes: 9e42f715264f ("drivers: net: cpsw: add phy-handle parsing")
Signed-off-by: David Rivshin
Signed-off-by: David S. Miller
[SZ Lin (林上智): Tweak the patch to use original print function of dev_info()]
Signed-off-by: SZ Lin (林上智)
Signed-off-by: Greg Kroah-Hartman
commit d733f7542ad47cf73e033c90cf55158587e1d060 upstream.
If an emac node has a phy-handle property that points to something
which is not a phy, then a segmentation fault will occur when the
interface is brought up. This is because while phy_connect() will
return ERR_PTR() on failure, of_phy_connect() will return NULL.
The common error check uses IS_ERR(), and so missed when
of_phy_connect() fails. The NULL pointer is then dereferenced.
Also, the common error message referenced slave->data->phy_id,
which would be empty in the case of phy-handle. Instead, use the
name of the device_node as a useful identifier. And in the phy_id
case add the error code for completeness.
Fixes: 9e42f715264f ("drivers: net: cpsw: add phy-handle parsing")
Signed-off-by: David Rivshin
Signed-off-by: David S. Miller
[SZ Lin (林上智): Tweak the patch to use original print function of dev_info()]
Signed-off-by: SZ Lin (林上智)
Signed-off-by: Greg Kroah-Hartman
Elaborate the difference from
the original source
42. 42
Review cycle [9]
• When the -stable maintainers decide for a review cycle, the patches will be sent to
the review committee, and the maintainer of the affected area of the patch
(unless the submitter is the maintainer of the area) and CC: to the linux-kernel
mailing list.
• The review committee has 48 hours in which to ACK or NAK the patch.
• If the patch is rejected by a member of the committee, or linux-kernel members
object to the patch, bringing up issues that the maintainers and members did not
realize, the patch will be dropped from the queue.
• At the end of the review cycle, the ACKed patches will be added to the latest -
stable release, and a new -stable release will happen.
• Security patches will be accepted into the -stable tree directly from the security
kernel team, and not go through the normal review cycle. Contact the kernel
security team for more details on this procedure.