Documentation

From Driver Backports Wiki
(Difference between revisions)
Jump to: navigation, search
(Split documentation into two sections by mechanism supported)
(Workflows: Backport is built out-of-tree against older kernel, not "applied")
 
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
The Linux kernel backports project aims at backporting Linux '''upstream''' device drivers for usage on older kernels. Support is provided for using backports in '''package''' form, where a tarball is provided with subsystems/drivers from future kernels, and also with direct kernel integration support, where you can use backports to directly '''integrate''' subsystems/drivers from future kernels on older kernel trees. The point of the project is to provide a central mechanism for backporting device drivers for ''any'' subsystem and enable ''both'' users '''and''' developers to always focus on upstream Linux kernel development. The backports project shall '''never''' include proprietary drivers and by design does not allow usage of itself with proprietary drivers. Every backports release has been test compiled ''for usage'' against  all supported kernels, the oldest one is (currently) 3.0. Note that Linux kernel releases can become deprecated. You are encouraged to use supported stable kernels as listed on [http://kernel.org kernel.org].
+
The Backports Project aims to backport current Linux '''upstream''' device drivers for use with older kernels. The objective (1) is to provide a central mechanism for backporting the device drivers of ''any'' subsystem, thereby enabling (2) ''both'' users '''and''' developers to always focus on upstream Linux kernel development.
  
<h2>Backport uses</h2>
+
The project shall '''never''' include proprietary drivers, and is designed to disallow its use with proprietary drivers.
  
  * Backports package releases
+
Every backports release has been test compiled ''for usage'' against all supported kernels. The oldest release is (currently) 3.0.
  * Backport kernel integration
+
  
<h2>Release types</h2>
+
Linux kernel releases can become deprecated. You are encouraged to use supported stable kernels as listed on [http://kernel.org kernel.org].
  
Both daily snapshots based on [http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git linux-next], and stable releases based [http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git Linux's stable releases] are provided. Always use the latest ''stable'' available release unless you need a feature / fix only currently available on the linux-next based release. A backports-3.x release means device drivers from the Linux v3.x release have been taken, backported and made available for you to use on any kernel version prior to the release version.
+
= Workflows =
  
<h2>Currently backported subsystems</h2>
+
Backports provides users with a choice of two workflows:
 +
 
 +
# '''kernel integration mode''' ([[Documentation/integration|documentation]])
 +
#* future kernel source tree and older kernel source tree must be present on the same machine at the same time
 +
#* backports suite '''integrates''' the subsystems/drivers of the future kernel directly into the older kernel
 +
# '''package releases mode''' ([[Documentation/packaging|documentation]])
 +
#* future kernel source tree and older kernel source tree do not need to be present on the same machine at the same time
 +
#* on machine hosting future kernel source tree, backport package is generated
 +
#* on machine hosting older kernel, backport package is built out-of-tree against older kernel
 +
#* backport package is loosely akin to a patch file
 +
 
 +
= Backported Subsystems =
  
 
Device drivers are available for the following subsystems:
 
Device drivers are available for the following subsystems:
  
  * Ethernet
+
* Ethernet
  * Wireless
+
* Wireless
  * Bluetooth
+
* Bluetooth
  * NFC
+
* NFC
  * ieee802154
+
* ieee802154
  * Media
+
* Media
  * Regulator
+
* Regulator
 +
 
 +
= Backported Drivers =
  
 
Whether or not a device driver is available from a subsytem will depend on whether or not a developer decided to backport it '''and''' if the device driver is backported down to the kernel you are on. If you see the driver on '''make menuconfig''' it means you can use it. An alternative is to look at the git tree [https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/tree/dependencies dependencies] file. Note that the [https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/tree/dependencies dependencies] '''does not''' exist on a final release, it only exists on the development git tree and the one linked here is the one on the master branch -- you should look at the [https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/refs/ release branches] for their respective dependencies file if using an older release. Someone is welcome to come up with a fancy page that provides the device driver <--> kernel dependency map page. If a device driver is available on '''make menuconfig''' but is not listed on the [https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/tree/dependencies dependencies] file it means it is available for usage on all supported kernel.
 
Whether or not a device driver is available from a subsytem will depend on whether or not a developer decided to backport it '''and''' if the device driver is backported down to the kernel you are on. If you see the driver on '''make menuconfig''' it means you can use it. An alternative is to look at the git tree [https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/tree/dependencies dependencies] file. Note that the [https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/tree/dependencies dependencies] '''does not''' exist on a final release, it only exists on the development git tree and the one linked here is the one on the master branch -- you should look at the [https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/refs/ release branches] for their respective dependencies file if using an older release. Someone is welcome to come up with a fancy page that provides the device driver <--> kernel dependency map page. If a device driver is available on '''make menuconfig''' but is not listed on the [https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/tree/dependencies dependencies] file it means it is available for usage on all supported kernel.
Line 26: Line 38:
 
Users should just install what they ''know'' they need, if not sure don't enable a driver. Typically Linux distributions would use the backports project and build modules for you and you'd have a backports package available for your distribution.
 
Users should just install what they ''know'' they need, if not sure don't enable a driver. Typically Linux distributions would use the backports project and build modules for you and you'd have a backports package available for your distribution.
  
<h2>Usage guide</h2>
 
 
Building backports follows the same build mechanism as building the Linux kernel.
 
 
<pre>
 
# as a user
 
make menuconfig
 
make -j4
 
# as root
 
make install
 
# reboot and enjoy
 
</pre>
 
 
Its understood users may not know how to configure the backports package, just like they may not know how to configure the Linux kernel, so a short cut is provided with default configuration files that can be used to only build their drivers / subsystems of interest. You can also just query the regular help menu.
 
 
<pre>
 
make help
 
make defconfig-help
 
</pre>
 
 
If you use this option just use the 'make defconf-option' in replacement for ''make menuconfig'' above. For example to compile all wifi drivers:
 
 
<pre>
 
# as a user
 
make defconfig-wifi
 
make -j4
 
# as root
 
make install
 
</pre>
 
 
Note that there are only default configuration files written for a few drivers while the project actually backports a lot of device drivers, the reason we have default configuration files for a few drivers is simply because developer have provided a default config options for them. What we really need is a 'make localmodconfig' support but that will take a while given that it involves mapping older kernel configs to newer kernel configs (which likely would be welcomed upstream as well).
 
 
<h2>Cross compiling</h2>
 
 
To cross compile:
 
 
set -a
 
CROSS_COMPILE=${CROSS_COMPILE}
 
ARCH=${TARGET_CPU}
 
KLIB_BUILD=${DEV_PATH}/${LINUX_DIR}
 
KLIB=${TARGET_ROOT_ON_HOST}
 
set +a
 
make oldconfig  # menuconfig worked here too
 
make
 
make install
 
 
The 'make install' target isn't currently sane for cross-builds due to the bacport_firmware_install script not respecting prefixes.  For now you can comment out that script few others like initrd updates, from being run out of the Makefiles.
 
 
<h2>Cross compile with Freescale's LTIB</h2>
 
 
To get backports happy in LTIB, use UNSPOOF/SPOOF_PATH to switch between host and cross environment.  Example <i>Build</i> section in backports.spec
 
 
  %Build
 
  export PATH=$UNSPOOF_PATH
 
 
 
  make menuconfig prefix=%{_prefix} \
 
    CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
 
    ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
 
    KLIB_BUILD=${TOP}/rpm/BUILD/linux
 
 
 
  export PATH=$SPOOF_PATH
 
 
 
  make prefix=%{_prefix} \
 
    CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \
 
    ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \
 
    KLIB_BUILD=${TOP}/rpm/BUILD/linux
 
  
 
[[File:88x31.png‎]] - This text is licensed under a [https://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 Unported License].
 
[[File:88x31.png‎]] - This text is licensed under a [https://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 Unported License].

Latest revision as of 21:38, 21 July 2017

The Backports Project aims to backport current Linux upstream device drivers for use with older kernels. The objective (1) is to provide a central mechanism for backporting the device drivers of any subsystem, thereby enabling (2) both users and developers to always focus on upstream Linux kernel development.

The project shall never include proprietary drivers, and is designed to disallow its use with proprietary drivers.

Every backports release has been test compiled for usage against all supported kernels. The oldest release is (currently) 3.0.

Linux kernel releases can become deprecated. You are encouraged to use supported stable kernels as listed on kernel.org.

[edit] Workflows

Backports provides users with a choice of two workflows:

  1. kernel integration mode (documentation)
    • future kernel source tree and older kernel source tree must be present on the same machine at the same time
    • backports suite integrates the subsystems/drivers of the future kernel directly into the older kernel
  2. package releases mode (documentation)
    • future kernel source tree and older kernel source tree do not need to be present on the same machine at the same time
    • on machine hosting future kernel source tree, backport package is generated
    • on machine hosting older kernel, backport package is built out-of-tree against older kernel
    • backport package is loosely akin to a patch file

[edit] Backported Subsystems

Device drivers are available for the following subsystems:

  • Ethernet
  • Wireless
  • Bluetooth
  • NFC
  • ieee802154
  • Media
  • Regulator

[edit] Backported Drivers

Whether or not a device driver is available from a subsytem will depend on whether or not a developer decided to backport it and if the device driver is backported down to the kernel you are on. If you see the driver on make menuconfig it means you can use it. An alternative is to look at the git tree dependencies file. Note that the dependencies does not exist on a final release, it only exists on the development git tree and the one linked here is the one on the master branch -- you should look at the release branches for their respective dependencies file if using an older release. Someone is welcome to come up with a fancy page that provides the device driver <--> kernel dependency map page. If a device driver is available on make menuconfig but is not listed on the dependencies file it means it is available for usage on all supported kernel.

Users should just install what they know they need, if not sure don't enable a driver. Typically Linux distributions would use the backports project and build modules for you and you'd have a backports package available for your distribution.


88x31.png - This text is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Personal tools