User:Knuxify/Draft:Getting started: Difference between revisions

Line 1:

This page serves as an introduction to the basics of mainlining.

== What is mainlining? ==

'''Mainlining''' is the act of adding support for a device, or porting its drivers from an older, non-upstream tree, to the mainline Linux kernel.

The name comes from the term "''mainline Linux kernel''", which is used to refer to the upstream Linux kernel repository maintained by Linus Torvalds<ref>https://en.wikipedia.org/wiki/Linux_kernel#Mainline_Linux</ref>, and which itself comes from the term "''mainline branch''" used to refer to the main development trunk of a project<ref>https://en.wikipedia.org/wiki/Branching_(version_control)#Trunk</ref>.

=== Why is mainlining necessary? ===

Users of the Linux kernel on x86-64 PCs may be accustomed to the fact that most components work out of the box on these devices. This can be partly attributed to the fact that both AMD and Intel - the largest players in the x86-64 market - contribute support for their CPUs and chipsets directly to the mainline Linux kernel.

With most embedded SoCs, however, the typical lifecycle of Linux support looks like this:

* The SoC vendor forks the Linux kernel and applies patches for device support on top of this fork

* The SoC fork is sent to device manufacturers, who apply their own patches on top of it to add support for their devices

The code from these forks usually never makes it back upstream; it's maintained internally by the SoC vendor's team. Yet worse, device vendors often neglect rebasing their forks on the vendor's updated kernels. As kernel APIs change over time, updating these kernels to the latest version becomes more difficult.

Since upstreaming is not a priority, and the main goal of a vendor is to provide a viable product to developers as fast as possible, the drivers in an SoC fork don't necessarily conform to the standards and practices of the mainline Linux kernel.

This is where '''mainlining''' comes in. Mainlining comprises of:

* Analyzing the drivers from original source code, or experimenting with the hardware itself to determine how it works (reverse engineering), to then write new, upstream-ready drivers for it;

* Submitting those drivers upstream, responding to review comments, maintaining them in the mainline Linux kernel tree.

== Prerequisites ==

Line 70:

Line 94:

== References ==

@@ Line 1: / Line 1: @@
 This page serves as an introduction to the basics of mainlining.
+== What is mainlining? ==
+'''Mainlining''' is the act of adding support for a device, or porting its drivers from an older, non-upstream tree, to the mainline Linux kernel.
+The name comes from the term "''mainline Linux kernel''", which is used to refer to the upstream Linux kernel repository maintained by Linus Torvalds<ref>https://en.wikipedia.org/wiki/Linux_kernel#Mainline_Linux</ref>, and which itself comes from the term "''mainline branch''" used to refer to the main development trunk of a project<ref>https://en.wikipedia.org/wiki/Branching_(version_control)#Trunk</ref>.
+=== Why is mainlining necessary? ===
+Users of the Linux kernel on x86-64 PCs may be accustomed to the fact that most components work out of the box on these devices. This can be partly attributed to the fact that both AMD and Intel - the largest players in the x86-64 market - contribute support for their CPUs and chipsets directly to the mainline Linux kernel.
+With most embedded SoCs, however, the typical lifecycle of Linux support looks like this:
+* The SoC vendor forks the Linux kernel and applies patches for device support on top of this fork
+* The SoC fork is sent to device manufacturers, who apply their own patches on top of it to add support for their devices
+The code from these forks usually never makes it back upstream; it's maintained internally by the SoC vendor's team. Yet worse, device vendors often neglect rebasing their forks on the vendor's updated kernels. As kernel APIs change over time, updating these kernels to the latest version becomes more difficult.
+Since upstreaming is not a priority, and the main goal of a vendor is to provide a viable product to developers as fast as possible, the drivers in an SoC fork don't necessarily conform to the standards and practices of the mainline Linux kernel.
+This is where '''mainlining''' comes in. Mainlining comprises of:
+* Analyzing the drivers from original source code, or experimenting with the hardware itself to determine how it works (reverse engineering), to then write new, upstream-ready drivers for it;
+* Submitting those drivers upstream, responding to review comments, maintaining them in the mainline Linux kernel tree.
 == Prerequisites ==
@@ Line 70: / Line 94: @@
 {{todo|pmOS wiki has links to talks and resources}}
+== References ==