diff options
42 files changed, 2589 insertions, 1804 deletions
diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..f65519e --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +build/** diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..d0c3cbf --- /dev/null +++ b/Makefile @@ -0,0 +1,20 @@ +# Minimal makefile for Sphinx documentation +# + +# You can set these variables from the command line, and also +# from the environment for the first two. +SPHINXOPTS ?= +SPHINXBUILD ?= sphinx-build +SOURCEDIR = source +BUILDDIR = build + +# Put it first so that "make" without argument is like "make help". +help: + @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) + +.PHONY: help Makefile + +# Catch-all target: route all unknown targets to Sphinx using the new +# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). +%: Makefile + @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) diff --git a/source/bugs.rst b/source/bugs.rst new file mode 100644 index 0000000..c0bbb0c --- /dev/null +++ b/source/bugs.rst @@ -0,0 +1,71 @@ +Bugs +==== + +Report **any bugs** you **think** you **may** have found because you are +working with the **latest and greatest drivers**! If your bug is +backport compatibility-related then we should still try to fix it within +the compatibility layer. If you are not sure you can let us help you. +**To date we have only have identified 2 backport related bugs**, all +other reported bugs were **real bugs** in **actual upstream** code! + +We are working on a bugzilla entry for compat / compat-drivers, until +then please report all bugs you think you my have found to the +:doc:`backports mailing list <mailing_list>` and if you know what subsystem +you think the bug belongs to Cc: the respective mailing list. Remember +that chances are **high** that the bug is not a backport bug but instead +a real upstream bug that **must** be fixed. + +What mailing lists to report bugs to +------------------------------------ + +Always use: **backports@vger.kernel.org** and then use one of the +following mailing lists depending on the subsystem from where your +driver belongs: + +- bluetooth: linux-bluetooth@vger.kernel.org +- wireless: linux-wireless@vger.kernel.org +- ethernet: netdev@vger.kernel.org + +Reporting security vulnerabilities +---------------------------------- + +If you have a security vulnerabilities issue to report and you know it +is backports related you can report this directly to the maintainers: + +- hauke@hauke-m.de +- mcgrof@kernel.org +- johannes@sipsolutions.net + +The report will be handled in private, once the issue is fixed and +propagated to users, the security fix will be disclosed and documented. +As of date we have had no security vulnerabilities issues reported. +Until then this page can be used to track updates on vulnerabilities +related to Linux backports. The attack surface to Linux backports +consists about 1-2% of code, this varies depending on what kernel you +are on. The older kernel you are on the higher the security risk. +Security issues on Linux should affect users of Linux backports if the +code is carried over into backports, fixes for that are addressed +through new release of backports with the corresponding upstream fixes. +Security fixes for Linux belong upstream on Linux, not on Linux +backports. To learn how to report Linux kernel security issues refer to +`SecurityBugs documentation +<https://www.kernel.org/doc/Documentation/SecurityBugs>`__. + +Bugzilla +-------- + +The Linux kernel bugzilla has an entry for backport bugs. + +Reporting new backport bugs +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To record a new bug: + +#. access the `Backports project <https://bugzilla.kernel.org/enter_bug.cgi?product=Backports%20project>`__ section of Bugzilla +#. select the *backports* component (it is the only component available) + +Viewing bugs by status +---------------------- + +- [https://bugzilla.kernel.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=Backports+project&content=. View open bugs] +- [https://bugzilla.kernel.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__closed__&product=Backports+project&content=. View closed bugs] diff --git a/source/code.rst b/source/code.rst new file mode 100644 index 0000000..4ceb072 --- /dev/null +++ b/source/code.rst @@ -0,0 +1,61 @@ +Code +==== + +In order to backport the Linux kernel we must divide and conquer the +tasks at hand. + +This is now deprecated use :doc:`hacking on backports <documentation/backports/hacking>`. + +Backport components +------------------- + +There are currently two components to the backports effort. + +compat +~~~~~~ + +compat is a shared module / headers that implements newer features for usage on older kernels. + +- git://github.com/mcgrof/compat.git>`__ +- :doc:`documentation/compat` + +compat-drivers +~~~~~~~~~~~~~~ + +compat-drivers is the framework that pulls code from the Linux kernel, +adds the compat module and backports features that compat could not +backport within its module / headers. + +- git://github.com/mcgrof/compat-drivers.git`` +- :doc:`documentation/compat-drivers` + +Getting all required code +------------------------- + +To be able to make releases and test building releases however you need +quite a bit more code. The setup is simplified with scripts from the +compat.git tree. To set your system up for the first time you can run:: + + wget https://github.com/mcgrof/compat/raw/master/bin/get-compat-trees + wget https://github.com/mcgrof/compat/raw/master/bin/get-compat-kernels + + chmod 755 get-compat-trees get-compat-kernels + + ./get-compat-trees + ./get-compat-kernels + +Hacking on the project +---------------------- + +You should realize that there are a few components to the project and +that although they are used together each one can be considered +independent of each other. + +- Read the :doc:`hacking on compat documentation <documentation/compat>` +- Read the :doc:`hacking on compat-drivers documentation <documentation/compat-drivers>` + +TODO list +~~~~~~~~~ + +Read the :doc:`hacking TODO <documentation/compat-drivers/hacking>` for +a list of wish items we should be working towards. diff --git a/source/conf.py b/source/conf.py new file mode 100644 index 0000000..d3f7037 --- /dev/null +++ b/source/conf.py @@ -0,0 +1,64 @@ +# Configuration file for the Sphinx documentation builder. +# +# This file only contains a selection of the most common options. For a full +# list see the documentation: +# http://www.sphinx-doc.org/en/master/config + +# -- Path setup -------------------------------------------------------------- + +# If extensions (or modules to document with autodoc) are in another directory, +# add these directories to sys.path here. If the directory is relative to the +# documentation root, use os.path.abspath to make it absolute, like shown here. +# +# import os +# import sys +# sys.path.insert(0, os.path.abspath('.')) + + +# -- Project information ----------------------------------------------------- + +project = 'Linux Backports' +copyright = '2024, Linux Backports Project' +author = 'kernel.org' + + +# -- General configuration --------------------------------------------------- + +# Add any Sphinx extension module names here, as strings. They can be +# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom +# ones. +extensions = [ +] + +# Add any paths that contain templates here, relative to this directory. +templates_path = ['_templates'] + +# List of patterns, relative to source directory, that match files and +# directories to ignore when looking for source files. +# This pattern also affects html_static_path and html_extra_path. +exclude_patterns = [] + + +# -- Options for HTML output ------------------------------------------------- + +# The theme to use for HTML and HTML Help pages. See the documentation for +# a list of builtin themes. +# +html_theme = 'sphinx_rtd_theme' +#html_theme = 'pydata_sphinx_theme' + +# Add any paths that contain custom static files (such as style sheets) here, +# relative to this directory. They are copied after the builtin static files, +# so a file named "default.css" will overwrite the builtin "default.css". +#html_static_path = ['media'] +#html_theme_options = { +# "show_nav_level": 2, +# "show_prev_next": False, +# "footer_start": ["copyright"], +# "footer_end": [], +#} + +# Don't highlight by default +highlight_language = 'none' + +master_doc = 'index' diff --git a/source/config-brainstorming.rst b/source/config-brainstorming.rst new file mode 100644 index 0000000..6ce2c77 --- /dev/null +++ b/source/config-brainstorming.rst @@ -0,0 +1,109 @@ +Config brainstorming +==================== + +Brainstorming for enable Kconfig on compat-drivers + +Step 1 +------ + +Using the existing kernel's config, generate a Kconfig file that +contains all the right symbols for that kernel:: + + cat .config | genkconf.sh > kernel-kconfig + +where the script is this: + +.. code-block:: bash + + #!/bin/bash + + while read line ; do + case "${line:0:7}" in + "CONFIG_") + line="${line:7}" + cfg="${line%%=*}" + val="${line#*=}" + cfgtype="skip" + if [ "$val" = "m" ] ; then + cfgtype="tristate" + elif [ "$val" = "y" ] ; then + cfgtype="bool" + fi + if [ "$cfgtype" != "skip" ] ; then + echo "config $cfg" + echo " $cfgtype" + echo " default $val" + echo "" + fi + ;; + "# CONFI") + cfg="${line:9}" + cfg="${cfg%% is not set}" + echo "config $cfg" + echo " bool" + echo " default n" + echo "" + ;; + esac + done + +Step 2 +------ + +Collect all Kconfig symbols from compat:: + + find . -name Kconfig | xargs cat | sed 's/^config //;t;d' > symbols + +Step 3 +------ + +Instead of patching Makefiles, replaces all CONFIG\_ by CONFIG_COMPAT\_ +in all Makefiles:: + + find . -name Makefile | xargs rpl "CONFIG_" "CONFIG_COMPAT_" + +This means that only things that are actually selected in compat will be built. + +Step 4 +------ + +Replace all "FOO" with "COMPAT_FOO" symbols in Kconfig and code files: + +.. code-block:: bash + + for sym in $(cat symbols) ; do + find . -name Kconfig |\ + xargs rpl -w "$sym" "COMPAT_$sym" + + find . -name '*.c' -o -name '*.h' |\ + xargs rpl -w "CONFIG_$sym" "CONFIG_COMPAT_$sym" + done + +Step 5 +------ + +Build a Kconfig file:: + + echo 'source "kernel-kconfig"' > Kconfig + for k in drivers/net/wireless/*/Kconfig ; do echo "source \"$k\"" >> Kconfig ; done + +etc. Currently, mac80211/cfg80211/... Kconfig isn't copied. They will +need to be copied and potentially modified for dependencies like WEXT. + +Step 6 +------ + +Run menuconfig:: + + /lib/modules/$(uname -r)/build/scripts/kconfig/mconf Kconfig + +Step 7 +------ + +Build the thing. + +The generated .config can be parsed with either the existing +compat-drivers/scripts/gen-compat-autoconf.sh script or +scripts/kconfig/confdata.c (conf --silentoldconfig). The generated +include/linux/compat_autoconf.h is already included as part of the build +of compat-drivers. diff --git a/source/documentation.rst b/source/documentation.rst new file mode 100644 index 0000000..f04e08b --- /dev/null +++ b/source/documentation.rst @@ -0,0 +1,92 @@ +Documentation +============= + +.. toctree:: + :maxdepth: 1 + + documentation/packaging + documentation/integration + documentation/compat + documentation/compat-drivers + documentation/compat-drivers/hacking + documentation/compat-drivers/additional-patches + documentation/backports/hacking + documentation/backports/hacking/todo + +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 +<https://kernel.org>`__. + +Workflows +--------- + +Backports provides users with a choice of two workflows: + +#. **kernel integration mode** (:doc:`documentation/integration`) + + - 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** (:doc:`documentation/packaging`) + + - 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: + +- Ethernet +- Wireless +- Bluetooth +- NFC +- ieee802154 +- Media +- 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 `dependencies +<https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/tree/dependencies>`__ +file. Note that the `dependencies +<https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/tree/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 +<https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/refs/>`__ +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 +<https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/tree/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. diff --git a/source/documentation/backports/hacking.rst b/source/documentation/backports/hacking.rst new file mode 100644 index 0000000..72c64a1 --- /dev/null +++ b/source/documentation/backports/hacking.rst @@ -0,0 +1,406 @@ +Documentation/backports/hacking +=============================== + +.. note:: + + the backports project's process is being reworked and redefined. + Some of the information in this page may be outdated and will be + updated when the changes in the process are finalized. + +The project has a :doc:`To-Do List <hacking/todo>` and a :doc:`License +<../../license>`. + +Philosophy +---------- + +The project aims to optimize the backporting process by not only +providing backported drivers but by also aiming to `automatically +backport the Linux kernel +<http://www.do-not-panic.com/2012/08/automatically-backporting-linux-kernel.html>`__ +by `optimizing backporting collateral evolutions +<http://www.do-not-panic.com/2012/08/optimizing-backporting-collateral.html>`__. + +Backports development flow +-------------------------- + +#. The `backports.git + <https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git>`__ + "master" development branch always tracks "linux-next", allowing it + to track all the development trees. + + - This ensures that, at the close of each merge window, the state of + the backports will be very close to the state of the first release + candidate. + +#. At the close of each merge window, the Backports Project creates a new branch. + + - This new branch tracks the progress of the impending release + throughout the release candidate evaluation period, to the major + release, and on to its lifetime as a stable kernel. + +The backports project thus makes three kinds of backports releases possible: + +- those derived from linux-next +- those derived from the most recent release candidate (if any) +- those derived from recent stable kernels. + +Backports git tree tags and branches +------------------------------------ + +The project uses two types of git tags: + +- daily tags following linux-next +- stable tags following either Linus' tree for rc releases or Greg's + stable tree for stable extra version releases + +The project uses a master branch and a series of stable branches, a +stable branch to track each stable release of the kernel. The master +branch always tags linux-next, for example the backports tag +backports-20141114 supports using linux-next tag next-20141114. Once +Linus makes a release candidate of the kernel a respective *stable +backports branch* is created based on the version of Linux Linus +released, this backports branch will be based on a recent backports tag +which was tracking linux-next. Future release candidates of the same +version of Linux as well as stable release of Linux under the same +version will be backported using the respective *backports stable +branch* created. + +If any of this is fuzzy please refer to the `Increasing Automation in +the Backporting of Linux Drivers Using Coccinelle +<https://github.com/mcgrof/paper-backports/raw/master/paper.pdf>`__ +paper, in particular the sections: + +- 1A - A. The Linux kernel development model +- 1B - A brief history of the Linux kernel backports project + +Git trees you will need +======================= + +The project backports a few subsystems down to older kernels. To be able +to synchronize backporting the latest and greatest the `linux-next.git +<https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git>`__ +tree is used as its main source for kernel updates. backports brings a +general kernel compatibility part containing some backported c functions +and header files in addition to patches for code in linux-next to make +it work on older kernel versions and with the general kernel +compatibility part. You will need first the `backports.git +<https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git>`__ +tree. Once cloned you can run:: + + ./devel/backports-update-manager + +That will get you all other trees and sources required for development, +which are: + +- linux-next - Stephen Rothwell's tree which tracks all development trees daily +- linux - Linus' tree +- linux-stable - Greg's stable tree for stable extra version releases + +This will use git clone --reference to minimize disk usage. + +You can generate backports based on different trees depending on your +needs. We are supporting build based on `linux-next.git +<https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/>`__, +`linux.git +<https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/>`__ +and `linux-stable.git +<https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/>`__. +You can also generate builds based on your own tree, but then you +probably have to patch backports yourself to add support for that. + +Tool prerequisites +------------------ + +git, python patch and coccinelle are needed to generate a backports +release. The tools will complain if you do not have any of the required +dependencies. + +Generate new release +-------------------- + +To generate a own backport release based on linux-next you need the +following git trees:: + + git://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git + git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git + +As linux-next changes often you should start with a working version by +using a tagged version from linux-next.git and backports.git with the +same date in it like backports-20130607 and next-20130607. This is a +combination where someone already tested that the patches are still +applying. + +After you have checked out some version of these git trees, you can +start generating a tar by running ./gentree.py in the backports tree. +This will take the path to the already checked out linux-next kernel as +the second last argument and the path to a directory where the newly +created release should be written to as the last parameter. The releases +are not created in place any more, but in a new path specified in the +last parameter:: + + ./gentree.py --clean --git-revision v3.x /path/to/your/linux-next /path/to/your/newly/created/release + +Adding new driver +================= + +This is a list of steps to be done when adding a new driver. Not all +steps are needed for every new driver it depends on what type of driver +is added. You can take the patch adding support for the ieee802154 +subsystem as a reference: +https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/commit/?id=a42aa4d474e5859164a00bf451970fb58b676fcf + +You should target the master branch of the backports repository. + +#. Add directories and files that should be copied from the mainline kernel to ``copy-list`` +#. Add patches to ``patches/collateral-evolutions/`` if needed, it is better to add or modify a header file in ``backport/backport-include/`` than adding a patch. +#. Add reference to the newly added driver directory in ``backport/Makefile.kernel`` if needed (just needed for new substems) +#. Add reference to the newly added driver directory in ``backport/Kconfig.sources`` if needed (just needed for new subsystems) +#. Add a defconfig file for this driver in ``backport/defconfigs/`` and modify other defconfig files if appropriate, e.g. if you add a wifi driver add it to ``backport/defconfigs/wifi`` +#. If the driver does not build on all kernel versions specify a minimum kernel version in ``dependencies`` + +Backports currently supports the latest minor version of every mainline +kernel starting from 2.6.24. You should check that backports still +builds after making your changes. To do so you should install all +supported kernel with the script in ``devel/get-compat-kernels`` and +then run ``devel/ckmake`` to build backports against every kernel +version. + +Backporting a kernel feature +---------------------------- + +Features being backported should either be backported into a respective +backports-3.x.c file under backports/compat/ and/or their respective +header file under backport/backport-include/. + +Backports Kconfig operation +--------------------------- + +Go read the `backports kconfig operation +<https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/tree/devel/doc/kconfig-operation>`__ +documentation. + +Backports Makefile operation +---------------------------- + +Go read the `backports Makefile operation +<https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/tree/devel/doc/makefile-operation>`__ +documentation. + +Sending patches +--------------- + +backports contributions follow the contribution model implemented by the +Linux kernel. Patches or pull requests for backports must have be +signed-offed. If you don't sign off on them **they will not accepted**. +This means adding a line that says "Signed-off-by: Name " at the end of +each commit, indicating that you wrote the code and have the right to +pass it on as an open source patch. For exact definition of what the +Signed-off-by tag is you can read the definition of the "**Developer's +Certificate of Origin 1.1**", which you can read here: + +http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html + +Remember there are three trees. linux-next itself is a conglomeration of +kernel git trees itself, so patches for linux-next.git should be sent to +each respective subsystem for which the patches are targeted for. So for +example for 802.11 you will want to send them to John Linville and cc +linux-wireless, for further guidelines on this see the `Submitting +Patches guidelines for 802.11 +<http://wireless.kernel.org/en/developers/Documentation/SubmittingPatches>`__. +As another example, for bluetooth you will want to send them to Gustavo +Padovan and cc the linux-bluetooth mailing list. If your patch touches +on others areas of the kernel refer to the MAINTAINERS file on the +kernel. + +For backports.git please send patches against to:: + + To: hauke@hauke-m.de, mcgrof@kernel.org + CC: backports@vger.kernel.org + Subject: [PATCH] backports: fix foo + +Patches are preferred sent with a clear commit log entry, if unfamiliar +with how to send patches please refer to `a git guide +<http://wireless.kernel.org/en/developers/Documentation/git-guide>`__. + +Requirements for contributions +------------------------------ + +The code quality, and coding style is precisely the same as followed by +the Linux kernel, for that refer to `the Linux kernel SubmittingPatches +<https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches>`__ +guide. Other than this, since we a supporting backporting you are +expected to refer to the respective upstream commit which you are +providing a backport for. This should describe both the git commit +sha1sum on Linux, and the commit description. The description should +also include the Linux kernel version which merged the commit upstream +first, this can be used to help understand what target kernels the +backport work was for. An example of good commit log follows:: + + commit 54584122b3279700f5ef2ba4f260a84273215947 + Author: Stefan Assmann <sassmann@kpanic.de> + Date: Fri May 16 13:21:19 2014 +0200 + + backports: handle new get_module_info and get_module_eeprom pointers in struct ethtool_ops + + In kernel 3.5 struct ethtool_ops received 2 new function pointers + get_module_info and get_module_eeprom. Address this by putting ifdef around + the code. + + commit 41c3cb6d20f0252308e9796fa4f3dacb4960de91 + Author: Stuart Hodgson <smhodgson@solarflare.com> + Date: Thu Apr 19 09:44:42 2012 +0100 + + ethtool: Extend the ethtool API to obtain plugin module eeprom data + + git describe --contains 41c3cb6d20f0252308e9796fa4f3dacb4960de91 + v3.5-rc1~109^2~124^2~2 + + Signed-off-by: Stefan Assmann <sassmann@kpanic.de> + Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> + +Backporting preference for EXPORT_SYMBOL_GPL() and proprietary drivers +---------------------------------------------------------------------- + +This framework was designed by intent since its inception **only** for +*upstream* Linux kernel drivers to avoid excuses about the difficulty to +support **upstream** Linux kernel development while also supporting +**users on older kernels**. To ensure the intent is respected currently +all symbols that we do work on to backport are exported via +**EXPORT_SYMBOL_GPL()** as we do work to backport them for the supported +kernels. By using EXPORT_SYMBOL_GPL() we make it **clear** through the +only current technical means we have that if you use the backported +symbols your software **is considered derivative works of the Linux +kernel**. + +Backporting more subsystems +--------------------------- + +Feel free to any backport subsystems. The requirement is you at least +list its kernel dependency and also that you have tested compilation +success with ckmake. If you are adding a new subsystem we are in hopes +you will also help maintain it. + +Generating backports stats +-------------------------- + +To help backports developers evaluate the gains of use of Coccinelle +SmPL a tool has been written as part of the work done towards the +`Increasing Automation in the Backporting of Linux Drivers Using +Coccinelle paper +<http://coccinelle.lip6.fr/papers/backport_edcc15.pdf>`__, the tool has +a temporary git tree on github, integration of the tool into the +upstream backports tree is desirable but porting of the tool to Python +must be done first. Below are instructions on how to use the tool to get +stats on the latest tree. The statistics give a slew of metrics over the +gains of using of Coccinelle towards automatically backporting the Linux +kernel on each release. + +First git clone upstream backports git tree, and have a linux-next tree +available (using Linus' tree is possible as well, you just need to use +the respective stable backports branch). Then generate a backports +release using --gitdebug so that each step of the backports process +creates a commit. This lets the tool evaluate the impact of using +Coccinelle at each step. Assuming you have backports cloned on +~/backports/ and the latest linux-next tree with the respective +linux-next tag associated with the latest backports tree tag you would +do:: + + cd linux-next git reset --hard next-20151218 + cd ~/backports/ + mkdir -p ~/build/ rm -rf ~/build/backports-20151218 ./gentree.py --gitdebug ~/linux-next ~/build/backports-20151218 + +Now go get the temporary backports stats tool and copy over the required +binary and script:: + + cd ~/ git clone https://github.com/mcgrof/backports-cocci-stats.git cd backports-cocci-stats make + cp gen-cocci-stats.sh ~/build/backports-20151218/ cp clean ~/build/backports-20151218/ + +Now generate the stats, you should see something like this:: + + mcgrof@ergon ~/build/backports-20151218 (git::master)$ ./gen-cocci-stats.sh + Development and Maintenance efficiency metrics: + + dev-efficiency maint-efficiency diff-wc diffstat clean SmPL-Patch + 0.555556 2.33333 21 5 9 0065-ndisc_send_na-argument.cocci + 2.75 8 64 22 8 0062-iff-no-queue.cocci + 0.666667 1.88889 17 6 9 skb_no_xmit_more.cocci + 1.16667 2.79167 67 28 24 ptp_getsettime64.cocci + 0.142857 1 14 2 14 features_check.cocci + 1.18182 5.45455 60 13 11 0055-netdev-tstats.cocci + 1.55906 3.55118 451 198 127 0054-struct-proto_ops-sig.cocci + 0.666667 1.88889 17 6 9 no-pfmemalloc.cocci + 0.634146 1.4878 61 26 41 set_vf_rate.cocci + 3.75 10.625 85 30 8 igb_pci_error_handlers.cocci + 1.07692 4.23077 55 14 13 ethtool_cmd_mdix.cocci + 0.588235 1.23529 21 10 17 rxnfc.cocci + 0.285714 1.53571 43 8 28 get_module.cocci + 0.285714 1.53571 43 8 28 ethtool_eee.cocci + 0.714286 2.28571 16 5 7 skb_no_fcs.cocci + 0.25 1.59375 51 8 32 set_vf_spoofchk.cocci + 0.428571 2.85714 40 6 14 sriov_configure.cocci + 0.87037 2.7037 146 47 54 0031-sk_data_ready.cocci + 4.4 17.9 179 44 10 genl-const.cocci + 7.11111 49.6667 447 64 9 0019-usb_driver_lpm.cocci + 0.571429 4.14286 58 8 14 get_ts_info.cocci + 11.5333 45.4 681 173 15 0001-netlink-portid.cocci + 2.96667 16.35 981 178 60 0002-no_dmabuf.cocci + 0.444444 1.77778 32 8 18 0002-gpio-parent.cocci + 0.512821 1.89744 74 20 39 0002-group_attr_bus.cocci + 0.769231 2.79487 109 30 39 0001-group_attr_class.cocci + 1.47184 5.6484 3711 967 657 all-SmPL.cocci + + Patch total diff wc -l: 3075 SmPL total diff wc -l: 3711 Total total diff wc -l: 6786 + Patch diff % contribution: 45.3139 SmPL diff % contribution: 54.6861 + +Now say you wanted to generate stats for a newer release, say for stats +based on linux-next tag next-20160122, you would do:: + + cd ~/linux-next/ + git reset --hard next-20160122 + cd ~/backports/ + ./gentree.py --gitdebug ~/linux-next/ ~/build/backports-20160122 + cd ~/build/backports-20160122 + cp ~/backports-cocci-stats/gen-cocci-stats.sh . + cp ~/backports-cocci-stats/clean . + ./gen-cocci-stats.sh + + Development and Maintenance efficiency metrics: + + dev-efficiency maint-efficiency diff-wc diffstat clean SmPL-Patch + 0.4 2.6 13 2 5 0067-mdio-addr.cocci + 0.555556 2.33333 21 5 9 0065-ndisc_send_na-argument.cocci + 2.75 8 64 22 8 0062-iff-no-queue.cocci + 0.666667 1.88889 17 6 9 skb_no_xmit_more.cocci + 1.16667 2.79167 67 28 24 ptp_getsettime64.cocci + 0.142857 1 14 2 14 features_check.cocci + 1.18182 5.45455 60 13 11 0055-netdev-tstats.cocci + 1.55906 3.55118 451 198 127 0054-struct-proto_ops-sig.cocci + 0.666667 1.88889 17 6 9 no-pfmemalloc.cocci + 0.634146 1.4878 61 26 41 set_vf_rate.cocci + 3.75 10.625 85 30 8 igb_pci_error_handlers.cocci + 1.07692 4.23077 55 14 13 ethtool_cmd_mdix.cocci + 0.588235 1.23529 21 10 17 rxnfc.cocci + 0.285714 1.53571 43 8 28 get_module.cocci + 0.285714 1.53571 43 8 28 ethtool_eee.cocci + 0.714286 2.28571 16 5 7 skb_no_fcs.cocci + 0.25 1.59375 51 8 32 set_vf_spoofchk.cocci + 0.428571 2.85714 40 6 14 sriov_configure.cocci + 0.87037 2.7037 146 47 54 0031-sk_data_ready.cocci + 4.4 17.9 179 44 10 genl-const.cocci + 7.11111 49.6667 447 64 9 0019-usb_driver_lpm.cocci + 0.571429 4.14286 58 8 14 get_ts_info.cocci + 11.5333 45.4 681 173 15 0001-netlink-portid.cocci + 2.96667 16.35 981 178 60 0002-no_dmabuf.cocci + 0.444444 1.77778 32 8 18 0002-gpio-parent.cocci + 0.512821 1.89744 74 20 39 0002-group_attr_bus.cocci + 0.769231 2.79487 109 30 39 0001-group_attr_class.cocci + 1.46375 5.62538 3724 969 662 all-SmPL.cocci + + Patch total diff wc -l: 3087 SmPL total diff wc -l: 3724 Total total diff wc -l: 6811 + Patch diff % contribution: 45.3237 SmPL diff % contribution: 54.6763 + +See also +-------- + +- :doc:`To-Do List <hacking/todo>` +- :doc:`License <../../license>` diff --git a/source/documentation/backports/hacking/todo.rst b/source/documentation/backports/hacking/todo.rst new file mode 100644 index 0000000..07244b0 --- /dev/null +++ b/source/documentation/backports/hacking/todo.rst @@ -0,0 +1,120 @@ +Documentation/backports/hacking/todo +==================================== + +The Linux kernel backports TODO list. + +make localmodconfig support +--------------------------- + +The Linux kernel has *make localmodconfig* support, random users +shouldn't be expected to know what modules they need, so in order to +allow users to get only the drivers they need built we'd need something +similar to *make localmodconfig*. There are a few ways to do this. The +best way would be to get upstream a mapping of a kernel object of a +device to list its respective Kconfig. We'd also need a map of Kconfig +changes over time as the kernel advances so that if a user is on an +older system their old kobject Kconfig could be mapped to a new one. +This should require changes upstream. + +Other simpler solutions are to rely on 'lspci -k' output and map this to +respective device drivers but this solution would be PCI bus specific. +We should review how the upstream *make localmodconfig* currently works +and improve upon that to enable support for it on backports. + +Who's working on this? +~~~~~~~~~~~~~~~~~~~~~~ + +No one. + +Module namespaces +----------------- + +Module namespace can consist of either adding prefixes to existing +symbols or modifying the Linux kernel module data structure so that upon +request for a symbol it's own namespace can be inspected for its +requested namespace. The Linux kernel backports project embraces +prefixing backported versions of symbols by prefixing backported +versions of symbols with *backports\_*. A macro LINUX_BACKPORT() was +added to help with this. For example:: + + #define crc8 LINUX_BACKPORT(crc8) + +Andi Kleen introduced the modular structure modification version of +`module namespaces +<http://thread.gmane.org/gmane.linux.network/78674>`__ back in 2007 but +`Rusty Russell nacked these patches +<http://article.gmane.org/gmane.linux.kernel/606885>`__. Because of this +we're left with remapping modules to their own namespaces without +modifying the in-kernel module structure. It **may** be possible to +somehow provide module namespaces without requiring modifications to the +in-kernel module structure, but such mechanisms would end up being +hacks. We need to evaluate if we can figure a clever way to support this +that is not so error prone or if we want to respinning Andi's patches +with the intent to help support kernel backporting. + +Original motivation for module namespaces +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Here's a brain dump from Andi about the original motivation behind +module namespaces: + +The original intent was to provide a cleaner export symbol API. + +There are roughly two classes of exported symbols: + +- Generally usable, well designed, interfaces intended to be used by + multiple modules (e.g. functions for drivers to register themselves or + library functions) +- Special purpose exports that are only really for a single module, but + are not intended as a general interface. These interfaces are usually + not really clean and reusable. + +The idea was to mark the later special purpose exports with the name of +the module that is supposed to them. They wouldn't be available to +everybody else and wouldn't become part of the general kernel module +API. + +Motivations +~~~~~~~~~~~ + +At times Linux distributions may choose, for whatever support-nightmare +reasons, to support two versions of a subsystem module and have two +separate device drivers use a different version of that subsystem. The +reason this is ill-advised is we stand to gain by having development +done on the upstream and latest versions of each subsystem and drivers; +that backports framework allows you to get that. An example helps to +clarify here. Suppose a distribution wants to ship with an old version +of mac80211 and have the iwlwifi driver use it, but for ath9k they'd +want to ship the newer version of mac80211 and new version of ath9k. +This cannot be supported unless module namespaces are created. + +Another more reasonable motivation is to avoid regressions with features +/ symbols being updated only for backported drivers. Non-backported +drivers will use the non-backported version of the routine. This should +avoid regressions with non-backported drivers using these routines. + +Who's working on this? +~~~~~~~~~~~~~~~~~~~~~~ + +No one. + +DKMS support +------------ + +Someone seems to want add support for `DKMS +<https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support>`__. Who +was that? What benefits does this bring? Isn't DKMS for proprietary +modules? If so we don't want this support. We don't want proprietary +drivers using the Linux kernel backports framework. + +DKMS is for proprietary modules only because all proprietary modules are +out-of-tree, and DKMS is for all out-of-tree modules, whether they are +proprietary or not. Since Linux kernel backports are out-of-tree, DKMS +brings the benefit of automagically keeping existing backports active +when a new kernel is installed, rather than going back to the in-tree +modules with every new kernel. + +Who's working on this? +~~~~~~~~~~~~~~~~~~~~~~ + +No one diff --git a/source/documentation/compat-drivers.rst b/source/documentation/compat-drivers.rst new file mode 100644 index 0000000..dc0c4a7 --- /dev/null +++ b/source/documentation/compat-drivers.rst @@ -0,0 +1,212 @@ +Documentation/compat-drivers +============================ + +compat-drivers is the framework that **pulls** code from Linux kernel +releases and strives to backport them *automatically* for usage on older +Linux kernel releases. compat-drivers allows us to make releases of code +from newer Linux kernel releases and get the latest drivers to users +without having to recompile their entire kernel. + +Supported Linux kernel releases +------------------------------- + +The `kernel.org <http://kernel.org/>`__ archive hosts **all** kernel +releases. As the Linux kernel development moves on older kernels get +**deprecated** and a few kernels remain supported. It is imperative that +end users / system integrators / Linux distributions upgrade to newer +**supported** kernels regularly otherwise they may end up being stuck on +**unsupported** kernels. The compat-drivers project aims at **always** +providing support of newer drivers down to *at least* **all supported +Linux kernel releases** as listed on `kernel.org +<http://kernel.org/>`__. As it is though the project currently takes +backporting further and it does support a large amount of older +unsupported and deprecated Linux kernel releases. As it is right now all +21 older kernels are supported: 2.6.24 - 3.6. + +Release types +------------- + +There are two release types, linux-stable and linux-next releases, for +details refer to the :doc:`releases page <../releases>`. There are also +modifications to releases and an extra set of flags are appended to +releases depending on the series of types of patches applied to them. +For details on these different type of patches that can be applied onto +a release refer to the :doc:`legend of additional patches +<compat-drivers/additional-patches>` section. + +Backported subsystems +--------------------- + +There are three subsystems currently backported through this framework. + +- Ethernet +- Wireless +- Bluetooth + +The video drivers are currently on their way to being integrated. + +Subsystem requirements +~~~~~~~~~~~~~~~~~~~~~~ + +In order to compile and install modules from the compat-drivers releases +you will need to have your kernel headers installed on your system. As +you get new drivers though you may need to install newer firmware as +well so be sure to always have in synch your **/lib/firmware/** directly +with the latest firmware from the `linux-firmware.git tree +<http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=summary>`__. + +Each backported subsystem may also take advantage of newer userspace +APIs and as such you should upgrade each subsystem's recommended +userspace as documented here. + +Userspace upgrade for wireless +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +We recommend these the following 802.11 wireless userspace applications +should be upgraded: + +- `wireless-regdb <http://wireless.kernel.org/en/developers/Regulatory#The_regulatory_database>`__ +- `CRDA <http://wireless.kernel.org/en/developers/Regulatory/CRDA>`__ +- `iw <http://wireless.kernel.org/en/users/Documentation/iw>`__ +- `rfkill <http://wireless.kernel.org/en/users/Documentation/rfkill>`__ +- `linux-firmware <http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=summary>`__ +- `wpa_supplicant <http://wireless.kernel.org/en/users/Documentation/wpa_supplicant>`__ +- `hostapd <http://wireless.kernel.org/en/users/Documentation/hostapd>`__ + +Userspace upgrade for bluetooth +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Someone should edit this and update this. + +Userspace upgrade for ethernet +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Someone should edit this and update this. + +Building and installing +----------------------- + +This section covers how to use build and install compat-drivers. + +Selecting your driver +~~~~~~~~~~~~~~~~~~~~~ + +compat-drivers allows you to selectively build only one driver instead +of building all backported drivers. + +Extracting compat-drivers +------------------------- + +Extract the content of the package:: + + tar xvf compat-drivers-$(date -I).tar.bz2 + +If you know what driver you want you can use driver-select:: + + ./scripts/driver-select + +Selecting your driver can reduce the amount of time to compile +compat-drivers. It may also enable kernel compatibility down to older +kernels. If you want to restore compat-drivers to enable all drivers +again you can use:: + + ./scripts/driver-select restore + +If you do not see your driver in the supported list it means care has +not been taken to ensure it works with driver-select and you must just +build compat-drivers as a whole. + +Building and installing +----------------------- + +This section documents how to build and install compat-drivers. + +Building compat-drivers +~~~~~~~~~~~~~~~~~~~~~~~ + +Build the latest backported Linux subsystems:: + + cd compat-wireless-$(date -I) + make + +Installing compat-drivers +~~~~~~~~~~~~~~~~~~~~~~~~~ + +We use the updates/ directory so your distribution's drivers are left +intact. By default depmod will search for this directory first, but if +you find that it does not then check that your depmod.conf file lists +the search order correctly with *updates* appearing first (before +*built-in*). the package should automatically detect this for you and +deploy an update for you. + +:: + + sudo make install + +Uninstalling compat-drivers +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This nukes our changes to updates/ so you can go back to using your +distribution's supported drivers. + +:: + + sudo make uninstall + +Unloading your old distribution drivers +--------------------------------------- + +Since you might be replacing your old subsystem drivers you should first +try to unload all existing related drivers. We provide a mechanism to +unload all drivers:: + + sudo make unload + +If unsure just reboot. + +Loading compat-drivers +~~~~~~~~~~~~~~~~~~~~~~ + +Before loading modules you must first unload your old subsystem modules. +Read above how to do this. If you know what module you need you can +simply load the module using modprobe. If you are not sure you can just +reboot the box. + +Building for external kernels +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you have a kernel you do not have installed but yet want to build the +compat-drivers for it you can use this syntax:: + + make KLIB=/home/mcgrof/kernels/linux-2.6.27.22 \ + KLIB_BUILD=/home/mcgrof/kernels/linux-2.6.27.22 + +Additional patches +------------------ + +Read the :doc:`additional patches <compat-drivers/additional-patches>` +section for details of how **emergency** or **critical** fixes are dealt +with while still **prioritizing** Linux upstream development. + +Bugs +---- + +Please see the :doc:`reporting bugs section <../bugs>`. This +cannot be stressed enough: **to date we have only have identified 2 +backport related bugs**, all other reported bugs **were real bugs in +actual upstream code** so be sure to report any bugs found **ASAP**! + +License +------- + +This work is a subset of the Linux kernel as such we keep the kernel's +Copyright practice. Some files have their own copyright and in those +cases the license is mentioned in the file. All additional work made to +building this package is licensed under the GPLv2. + +Hacking compat-wireless +----------------------- + +If you'd like to hack on compat-drivers or make your own releases refer +to the :doc:`hacking compat-drivers page <compat-drivers/hacking>`. + diff --git a/source/documentation/compat-drivers/additional-patches.rst b/source/documentation/compat-drivers/additional-patches.rst new file mode 100644 index 0000000..f0cf027 --- /dev/null +++ b/source/documentation/compat-drivers/additional-patches.rst @@ -0,0 +1,225 @@ +Documentation/compat-drivers/additional-patches +=============================================== + +This is now deprecated use :doc:`hacking on backports <../backports/hacking>`. + +Additional patches to stable releases +------------------------------------- + +compat-drivers **prioritizes** pushing software to be **upstreamed** +into *respective* Linux subsystem development trees. The stable +compat-drivers releases are based on vanilla stable kernels and extra +version stable (3.x.y) releases as published through the +`linux-stable.git +<http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary>`__ +tree. Stable fixes are propagated through the `stable kernel fix +propagation mechanism +<http://wireless.kernel.org/en/users/Documentation/Fix_Propagation>`__. +At times however the `stable kernel fix propagation mechanism +<http://wireless.kernel.org/en/users/Documentation/Fix_Propagation>`__ +may not allow OEMs/OSVs/users to get the latest stable patches in time +for their own needs. Other times, some patches which are not necessarily +*"stable"* fixes may be desired to be integrated into a stable release +by a hardware manufacturer, for one reason or another. At times, a +subsystem maintainer may be on vacation and stable fix patches may take +a while to get to users. In the worst case scenario some patches may not +have been submitted for public review yet, for whatever reason, but it +may be desired to merge some temporary patches on a stable release. +Because of all these reasons compat-drivers has extended the `stable +kernel fix propagation mechanism +<http://wireless.kernel.org/en/users/Documentation/Fix_Propagation>`__ +by enabling additional types of patches to be merged into a stable +release. **Upstream first** is still prioritized by categorizing these +patches. + +There are five categories to compat-wireless' extra patches: + +- pending-stable +- linux-next-cherry-picks +- linux-next-pending +- crap +- unified-drivers + +We document these below. + +Legend of additional patches +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Releases can either be vanilla releases or have a series of additional +patches applied to the release on top of the vanilla release. A flag is +appeneded at the end of a release to annotate patches from a specific +directory have been applied to this release. The appended extra flag +meanings follows:: + + * -s - get and apply pending-stable/ from linux-next.git + * -n - apply the patches linux-next-cherry-picks/ directory + * -p - apply the patches on the linux-next-pending/ directory + * -c - apply the patches on the crap/ directory + * -u - apply the patches on the unified-drivers/ directory + +Release with no extra flags are simply vanilla releases of the kernel. +Users / Linux distributions are encouraged to use the *-uspn* releases +if they are available, otherwise the *-spn* relases as these releases +will have extra fixes not yet propagated. The *-s* flag for example +indicates that the release has patches marked as stable which will be +released by the next 3.x.y release of the kernel so you might as well +get them now. Linux distributions are encouraged to use the extra +flagged releases as well. We provide the vanilla releases for those +Linux distributions which just want vanilla for whatever reason. + +Each category is documented below. + +Annotating cherry pick preference +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you want to annotate that a patch should be considered for inclusion +into the stable releases of compat-drivers under +linux-next-cherry-picks/ you can annotate it by adding a tag on the +commit log line, *Cc: backports@vger.kernel.org*. An example follows. By +annotating these patch a script can be used to scrape linux-next for +extracting these patches when building a stable release:: + + commit 061acaae76dfb760f4f3fddf0cde43915b7d673c + Author: Luis R. Rodriguez <rodrigue@qca.qualcomm.com> + Date: Wed Dec 7 21:50:07 2011 +0530 + + cfg80211: allow following country IE power for custom regdom cards + + By definition WIPHY_FLAG_STRICT_REGULATORY was intended to allow the + wiphy to adjust itself to the country IE power information if the + card had no regulatory data but we had no way to tell cfg80211 that if + the card also had its own custom regulatory domain (these are typically + custom world regulatory domains) that we want to follow the country IE's + noted values for power for each channel. We add support for this and + document it. + + This is not a critical fix but a performance optimization for cards + with custom regulatory domains that associate to an AP with sends + out country IEs with a higher EIRP than the one on the custom + regulatory domain. In practice the only driver affected right now + are the Atheros drivers as they are the only drivers using both + WIPHY_FLAG_STRICT_REGULATORY and WIPHY_FLAG_CUSTOM_REGULATORY -- + used on cards that have an Atheros world regulatory domain. Cards + that have been programmed to follow a country specifically will not + follow the country IE power. So although not a stable fix distributions + should consider cherry picking this. + + Cc: backports@vger.kernel.org + Cc: Paul Stewart <pstew@google.com> + Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> + Cc: Senthilkumar Balasubramanian <senthilb@qca.qualcomm.com> + Reported-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> + Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> + Signed-off-by: John W. Linville <linville@tuxdriver.com> + +pending-stable patches +~~~~~~~~~~~~~~~~~~~~~~ + +These are patches merged into linux-next.git but that have not yet been +merged into the linux-stable.git tree. + +From the pending-stable/README:: + + Often right before the merge window we get a block on non + oops/regression fixes for stable fixes. Some stable fixes + often get propagated afterwards during the extraversion + maintenance of the kernels. Right before the merge window + circa rc4 and rc5 subsystem maintainers get pegged if they + throw in non oops/regression fixes for Linus or their + respective upstream maintainer. While this makes sense + for tree management and stable release considerations we + still need to get users some stable patches propagated. + + This directory is there to help with that. Only patches + which have been merged into linux-next.git will be included + in this directory which means you must post it and the maintainer + should have merged it and Stephen would have picked it up. + + This directory will always be empty for bleeding edge + releases as bleeding edge releases are always based on + linux-next already. This directory only makes sense for + stable release of the kernel, and it we will always try + to use it, in case there are stable fixes not yet propagated. + +linux-next-cherry-picks patches +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +From the linux-next-cherry-picks/README:: + + We work hard to get patches in time onto the stable + tree but sometimes a few things slip out, and sometimes a + stable fix is simply too big in size to be merged into + stable. In such cases though we do believe some of these + patches are still relatively important to either enable new + hardware which escaped the late rc cycles or to correct some + behaviour which might be too late for stable. We apply + these patches by default as they will be supported on these + releases. + + The larger the number of patches you see in this directory + the more we should be ashamed. We should strive to reduce this + to 0 all the time. + + This directory will always be empty for bleeding edge + releases as bleeding edge releases are always based on + linux-next already. + +linux-next-pending patches +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +From the linux-next-pending/README:: + + You must have a really good reason to be adding files + in this directory. The requirement is your patches must have + been posted to a public mailing list for the subsystem you are + working on. Each patch you add here must have a really good + explanation on the top of the file which clarifies why the + patch has not yet been merged OR specify it on the commit log + when you add it on compat-wireless. + + We try to avoid having patch files because but we understand + if you might because you need to test code posted but not yet + merged into linux-next or a stable kernel release. This can happen + often during the merge window, when the maintainers are unavailable, + on vacation, suck at what they do, or for any other uncontrollable + reasons. + +crap patches +~~~~~~~~~~~~ + +From the crap/README:: + + If you are including patches into this directory you + must be fixing some critical bug for a customer which needs + immediate release or immediate testing. + + Alternatively you would use this to apply some sort of + crap code you are maintaining. + + You must have a really good reason to be adding files + in this directory. If possible you should explain your + reasoning of why the patch is getting included here and + not upstream and why it hasn't even yet been posted. + + You should avoid these patches at all costs. + +unified-drivers patches +~~~~~~~~~~~~~~~~~~~~~~~ + +From the unified-drivers/README.md:: + + compat-drivers supports developers to supply a unified + driver git tree which is being used to target support + for getting the driver in line with requirements for + linux-next. Once the driver gets upstream the driver + gets removed and we cherry pick updated version of the + driver directly from linux upstream. + + The code provided on this tree must try to adhere to + conventions for targetting inclusion into linux-next. + The compat-drivers patches/unified-drivers/ directory + allows for any additional required backport delta to + be addressed for the supplied driver. This allows + development and transformation of the driver to always + be targetting linux-next and allows for backporting + to be dealt with separately. diff --git a/source/documentation/compat-drivers/hacking.rst b/source/documentation/compat-drivers/hacking.rst new file mode 100644 index 0000000..03aa979 --- /dev/null +++ b/source/documentation/compat-drivers/hacking.rst @@ -0,0 +1,248 @@ +Documentation/compat-drivers/hacking +==================================== + +This is now deprecated use :doc:`hacking on backports <../backports/hacking>`. + +This section deals with development details of compat / compat-drivers +and the other trees it uses. If you want to make your own compat-drivers +tarballs, or if you see something busted with compat-drivers or just +want to add something new or an enhancement this is the guide for you. + +Git trees you will need +----------------------- + +compat-drivers backports a few subsystems down to older kernels. To be +able to synchronize backporting the latest and greatest the +`linux-next.git +<http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary>`__ +tree is used as its main source for kernel updates. General Linux kernel +compatibility is addressed through a general kernel compatibility tree, +`compat.git <https://github.com/mcgrof/compat>`__. compat-drivers then +has its own tree for specific subystem target backports. You will then +need to checkout a few trees to start hacking on compat-drivers, you can +use the :doc:`instructions on getting all required code <../../code>` +to get all trees but below we provide the list of the git trees used. + +:: + + git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git + git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git + git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git + git://github.com/mcgrof/compat.git + git://github.com/mcgrof/compat-drivers.git + +Linux next +---------- + +The `linux-next.git +<http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary>`__ +tree brings all subsystems being worked on for the **next kernel +release** into one tree. So if the current rc kernel is v3.6-rc1, this +means linux-next will have what people today are working on for the 3.7 +kernel release. + +backports components +-------------------- + +Go read the :doc:`backports documentation <../../documentation>` for a list of +backport components and ensure you understand what each one is supposed +to do. Below is a quick description though for the big picture. + +compat.git +~~~~~~~~~~ + +The compat git tree is a general kernel compatibility layer which can be +shared amongst different compatibility projects, or drivers. +compat-drivers is just one of the kernel compatibility projects using +compat.git. compat.git builds a general compatibility module, compat, +and any additional modules to let you get new general kernel updates +from future kernels on your old kernels. + +compat-drivers.git +~~~~~~~~~~~~~~~~~~ + +Anything that is not general kernel compatibility but instead specific +to a subsystem goes into compat-drivers.git. After you've cloned all +three trees, linux-next.git, compat.git and compat-wireless.git you need +to change into the compat-drivers directory and tell compat-drivers +where you linux-next and compat.git trees are. You do this with +environment variables GIT_TREE and GIT_COMPAT_TREE. You can do for +example:: + + export GIT_TREE=/home/user/linux-next/ + export GIT_COMPAT_TREE=/home/users/compat/ + +Then you can then update your local sources based on these +linux-next.git and compat.git trees:: + + scripts/admin-clean.sh - Cleans the compat-drivers tree + scripts/admin-update.sh - Updates compat-drivers with your git tree + scripts/admin-refresh.sh - Does the above two + +Adding new drivers +------------------ + +Most new drivers are enabled for compilation. If see a driver you would +like enabled try adding it into the mix, test them and if they work +enable them and send the respective patches. + +Generating stable releases +-------------------------- + +You can make stable releases yourself by checking out the specific +branch for the target stable kernel release you want on each git tree: + +- `linux-stable.git <http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary>`__ +- `compat-drivers.git <https://github.com/mcgrof/compat-drivers>`__ +- `compat.git <https://github.com/mcgrof/compat>`__ + +You will also want an updated `linux-next.git +<http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary>`__, +you want to ensure that the tag for the target kernel you want is +present if you want to cherry pick out stable patches from it. So for +example if v3.5.1 was released you want to ensure the `linux-next.git +<http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary>`__ +tree you have is updated with the v3.5.1 tag. The `linux-next.git +<http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary>`__ +tree however is **not** carry the extra version stable releases however +though so to add these tags you can add the both the linux.git and +linux-stable.git as remotes to your **linux-next/.git/config** file:: + + [remote "next"] + fetch = +refs/heads/*:refs/remotes/origin/* + url = /home/mcgrof/linux/.git + [remote "stable"] + fetch = +refs/heads/*:refs/remotes/origin/* + url = /home/mcgrof/linux-stable/.git + +Then do on your linux-next directory:: + + git fetch next + git fetch -t next + git fetch stable + git fetch -t stable + +Now, for example if you wanted to make a v3.5.y stable release, you +would do:: + + # On linux-next.git: + mcgrof@tux ~/linux-next (git::master)$ git fetch + remote: Counting objects: 43056, done. + ... etc ... + mcgrof@tux ~/linux-next (git::master)$ git reset --hard origin + HEAD is now at 74bdbee Add linux-next specific files for 20110329 + # Now get kernel extraversions on linux-next.git, this allows you + # to extract stable patches from linux-next.git when the linux-2.6-allstable + # tree moves to a new extraversion release. + mcgrof@tux ~/linux-next (git::master)$ git fetch stable + mcgrof@tux ~/linux-next (git::master)$ git fetch -t stable + + # For compat-drivers.git: + mcgrof@tux ~/devel/compat-drivers (git::master)$ git checkout -b linux-3.5.y origin/linux-3.5.y + Branch linux-3.5.y set up to track remote branch linux-3.5.y from origin. + Switched to a new branch 'linux-3.5.y' + mcgrof@tux ~/devel/compat-drivers (git::linux-3.5.y)$ + + # For compat.git: + mcgrof@tux ~/compat (git::master)$ git checkout -b linux-3.5.y origin/linux-3.5.y + Branch linux-3.5.y set up to track remote branch linux-3.5.y from origin. + Switched to a new branch 'linux-3.5.y' + mcgrof@tux ~/compat (git::linux-3.5.y)$ + + # For linux-stable.git: + mcgrof@tux ~/linux-stable (git::master)$ git checkout -b linux-3.5.y origin/linux-3.5.y + Branch linux-3.5.y set up to track remote branch linux-3.5.y from origin. + Switched to a new branch 'linux-3.5.y' + +Once you have the appropriate branches checked out, you can use a script +designed to let you make a release: + +#. First tell compat-wireless scripts your target GIT_TREE +#. from where you want to suck out code from is the stable tree:: + + mcgrof@tux ~/devel/compat-drivers (git::linux-3.5.y)$ export GIT_TREE=/home/mcgrof/linux-stable/ + +#. Then generate a stable release:: + + mcgrof@tux ~/devel/compat-drivers (git::linux-3.5.y)$ ./scripts/gen-stable-release.sh -s -n + Skipping linux-stable git tree update checks for branch: linux-3.5.y + On linux-stable: linux-2.3.5.y + You said to use git tree at: /home/mcgrof/linux-stable for linux-next + Copying /home/mcgrof/linux-stable/include/linux/ieee80211.h + Copying /home/mcgrof/linux-stable/include/linux/ieee80211.h + Copying /home/mcgrof/linux-stable/include/linux/nl80211.h + Copying /home/mcgrof/linux-stable/include/linux/pci_ids.h + ... Creating compat-wireless-3.5.1-1-sn.tar.bz2 ... + + Compat-wireles release: compat-wireless-v3.5.1-1-sn Size: 4.3M + compat-wireless-v3.5.1-1-sn.tar.bz2 sha1sum: b0ca93dbda466b22ed76a8e4792c89931090d7b3 compat-wireless-v3.5.1-1-sn.tar.bz2 + Release: /tmp/staging/compat-wireless/compat-wireless-v3.5.1-1-sn.tar.bz2 + +Note that if you supplied the -s flag you will want to review the output +for the place where it generates the pending-stable patches. If the +respective target upstream tag was not found on linux-next.git it will +tell you. + +If you want to add additional non-upstream patches you can use the crap/ +directory and use the -c flag as well. When people review your tarball +they can then find your delta easily. If you submit patches upstream you +can stuff them into linux-next-pending/ and use -p. If your patch is +upstream on linux-next.git you can cherry pick it out and stuff it into +linux-next-cherry-picks/ and use -n. The purpose of all this effort is +to enable customizations but to also allow reviewers to quickly find +deltas and ensure code gets upstream properly. Check each respective +directory README for a review of the directories intent and content. + +Sending patches +--------------- + +compat and compat-drivers contributions follow the contribution model +implemented by the Linux kernel. Patches or pull requests for compat and +compat-drivers must have be signed-offed. If you don't sign off on them +**they will not accepted**. This means adding a line that says +"Signed-off-by: Name " at the end of each commit, indicating that you +wrote the code and have the right to pass it on as an open source patch. +For exact definition of what the Signed-off-by tag is you can read the +definition of the "**Developer's Certificate of Origin 1.1**", which you +can read here: + +http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html + +Remember there are three trees. linux-next itself is a conglomeration of +kernel git trees itself, so patches for linux-next.git should be sent to +each respective subsystem for which the patches are targeted for. So for +example for 802.11 you will want to send them to John Linville and cc +linux-wireless, for further guidelines on this see the `Submitting +Patches guidelines for 802.11 +<http://wireless.kernel.org/en/developers/Documentation/SubmittingPatches>`__. +As another example, for bluetooth you will want to send them to Gustavo +Padovan and cc the linux-bluetooth mailing list. If your patch touches +on others areas of the kernel refer to the MAINTAINERS file on the +kernel. + +For compat.git and compat-drivers.git please send patches against to:: + + To: Luis R. Rodriguez <mcgrof@kernel.org> + CC: backports@vger.kernel.org + Subject: [PATCH] compat-2.6: fix foo + +For patches for compat.git please use a subject like the following:: + + Subject: [PATCH] compat: fix foo + +For compat-drivers.git please use a subject like the following:: + + Subject: [PATCH] compat-drivers: fix foo + +Patches are preferred sent with a clear commit log entry, if unfamiliar +with how to send patches please refer to `a git guide +<http://wireless.kernel.org/en/developers/Documentation/git-guide>`__. + +TODO +---- + +- Dialog (make menuconfig) option for this package -- :doc:`../../config-brainstorming` +- Add support for `DKMS <https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support>`__ +- Add more subsystems +- media (e.g. DVB-T devices) + diff --git a/source/documentation/compat.rst b/source/documentation/compat.rst new file mode 100644 index 0000000..b804edc --- /dev/null +++ b/source/documentation/compat.rst @@ -0,0 +1,336 @@ +Documentation/compat +==================== + +This is now deprecated, use :doc:`hacking on backports <backports/hacking>`. + +This page is dedicated to compat, a generic Linux kernel backport +compatibility module that has been brewing since 2009. The compat module +provides functionality introduced in newer kernels to older kernels +through a set of header files and exported symbols. The compat module +allows code from newer kernel releases to be used on older kernels +without modifications with a few exceptions. Exceptions to achieve +automatically backporting kernel code through the compat module are +dealt with through specific mechanisms documented in the :doc:`compat-drivers +project page <compat-drivers>` and most recently through the `slides +used at the 2011 Linux Plumbers presentation on automatically +backporting the kernel +<http://www.linuxplumbersconf.com/2011/ocw/system/presentations/771/original/kernel-backport-for-good.odp>`__ +and its `follow up presentation +<https://docs.google.com/presentation/d/1axVNEGwKZjnzG1ocdd289WMqPxzJ3qfMv70ghGcnUKc/edit>`__ +at the 2012 Linux Collaboration summit in San Francisco. + +By using compat and frameworks such as :doc:`compat-drivers +<compat-drivers>`, and techniques to integrate `additional patches +<http://wireless.kernel.org/en/users/Download/stable/#Additional_patches_to_stable_releases>`__ +into upstream releases that prefer and push for upstream, we hope to +ensure developers can prioritize working directly upstream on the Linux +kernel and provide deliverables to end users and customers for any +target kernel. + +compat-drivers today automatically backports the `Wireless +<http://wireless.kernel.org/>`__, `Bluetooth <http://www.bluez.org/>`__ +and `Ethernet +<https://www.linuxfoundation.org/collaborate/workgroups/networking/ethernet>`__ +drivers directly from the Linux kernel on a daily basis by using +`linux-next.git +<http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary>`__. +We also make `stable backport releases +<http://wireless.kernel.org/en/users/Download/stable/>`__ by using the +`linux-stable.git +<http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary>`__ +tree. We are considering expanding this framework to automatically +backport more drivers -- patches are welcomed, otherwise, you'll have to +wait until someone decides to integrate other subsystems. + +Supported kernels +----------------- + +The goal is to backport new kernel functionality at least down to the +oldest stable supported kernel listed on `kernel.org +<https://kernel.org>`__, but backporting code further is certainly +welcomed. Currently this means supporting backporting down to the 2.6.27 +Linux kernel release. Although our goal is to at least support backport +efforts down to 2.6.27 the compat module currently has code to support +even older kernels, and we welcome code to support older kernels as +well. + +Mailing list +------------ + +See the :doc:`Backports mailing list <../mailing_list>` page. + +Presentations +------------- + +Metrics explaining the amount of code saved by automatically backporting +the kernel using compat and current research are explained. + +- `2011 Linux plumbers kernel backport presentation <http://linuxplumbersconf.org/2011/ocw/proposals/771>`__ (`slides <http://www.linuxplumbersconf.com/2011/ocw/system/presentations/771/original/kernel-backport-for-good.odp>`__) +- `follow up presentation Automatically backporting the Linux kernel - 2012 Linux Collaboration summit <https://docs.google.com/presentation/d/1axVNEGwKZjnzG1ocdd289WMqPxzJ3qfMv70ghGcnUKc/edit>`__ + +Estimating deliverables +----------------------- + +Once you use compat and kernel framework integrators such as +:doc:`compat-drivers <compat-drivers>` you should have no excuse to work +outside of the upstream Linux kernel. In order to help guestimate when +your upstream code will be available through a stable release such as +the :doc:`compat-drivers stable releases <../releases>` you can rely on +the `phb-crystall-ball <http://phb-crystal-ball.org/>`__. + +Tracking down when a feature went upstream +------------------------------------------ + +The compat module expect you to put functionality into either header +files for defines and static inlines or into c files. This functionality +must be tucked away under a file for the kernel release that introduced +the functionality. To help aid you with your scavenger hunt on tracing +down when a specific functionality was introduced into the upstream +Linux kernel you can use several techniques. This section documents +those techniques. + +Git tree setup for backporting +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In order to understand how to track a feature in the Linux kernel you +must first understand how the development of the Linux kernel happens. +Below we provide a basic description of how this works. + +Greg Kroah-Hartman maintained the stable series of the Linux kernel. +Linus hands off kernel maintainership to Greg after he blesses the first +release of a stable kernel. Greg maintains the stable kernel via through +the `linux-stable.git +<http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary>`__ +tree. Each stable release of the kernel has a respective +origin/linux-3.x.y branch, where x is the current release number. The +"y" here is literal, so for the 3.2 release there is an +origin/linux-3.2.y branch that keeps track of the 3.2.1, 3.2.2 and +future extra version releases of the 3.2 release. You can use the +`linux-stable.git +<http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary>`__ +tree to verify if code is present on a stable release of a kernel. + +Linus maintains the release candidates of the Linux kernel (RC) up to +the point he blesses away the first release of a kernel release. So for +example Linus maintained the 3.2 kernel from the inception of 3.2-r1 +down to 3.2-rc7. During the 3.2-rc1 to 3.2-rc7 release Linus is supposed +to only accept regression fixes. After that he releases the first +blessed release of 3.2 and handed off maintainership to Greg. All the +magic that went into 3.2-rc1 though happens in what we call the +development cycle of the Linux kernel. The development cycle of the +Linux kernel varies subsystem to subsystem but the idea can be best +described in terms of the usage of two subsystem git trees. Subsystem +maintainers typically have to maintain two git trees, a subsystem.git +tree and a subsystem-next.git tree. The subsystem.git tree contains code +that should go into Linus' tree during the regression testing of the RC +release of the kernel. The subsystem-next.git contains code is being +queued up for the next release of the Linux kernel, hence the "-next" +postfix. All code in the subsystem-next.git trees is ephemeral, that is, +what you see there today does not mean that it will be present tomorrow, +it is code that is simply accepted on that day by the subsystem +maintainer, but a lot of it can simply be dropped, and in fact Linus can +reject merging it eventually. Linus will start merging all +subsystem-next.git trees into his own tree during what we call, the +merge window. This typically consists of a 2-3 week window period. For +example the merge window for the 3.2 kernel started after Linus released +the v3.1 kernel release on Mon Oct 24, 2011, and ended when Linus +released the v3.2-rc1 release on Mon Nov 7, 2011, the merge window in +this case lasted exactly 2 weeks. + +The merge window can often be painful though and to aid with this +Stephen Rothwell has decided to take up merging all subsystem-next.git +trees into one tree, `linux-next.git +<http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary>`__ +on a daily basis. He rants to each subsystem maintainer on any issues +during his merge, including build breakage and general insanity. + +The implications here are that we can not only track code that is +already released, but we can also predict what likely will go into the +next release of the Linux kernel by using `linux-next.git +<http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary>`__. +This means we can backport the Linux kernel proactively through every +subsystem development cycle by using `linux-next.git +<http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary>`__. + +If this is still a bit fuzzy you can review the `wireless development +process <http://wireless.kernel.org/en/developers/process>`__ for a +review of how that specific subsystem development works. The development +process there even includes a shiny diagram. + +Using git grep to identify what file adds new functionality +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First you want to identify what file added the functionality you seek to +backport. Suppose you want to identify what file adds a new function, +foobar(). To do this you can use:: + + git grep foobar\( + +to identify where foobar() is used in the entire Linux kernel. git grep +will use the indexed data and at times can often run faster than a +regular grep, as it will also skip object file in a regular grep search. +Given that the point of compat is to backport functionality and that +this functionality is typically shared between modules and subsystems, +you can rest assured most functionality has a declaration in the header +files of the Linux kernel. You can typically save yourself git grep time +by starting to search through the include/ directory of the Linux +kernel. + +:: + + git grep foobar\( include/ + +Using git blame to identify introduction of a commit +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Typically compat will have a lot of features already backported for +older kernels, so to help backport new functionality you should be using +`linux-next.git +<http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary>`__. +To identify at what point a specific feature was added into the Linux +kernel you can use git blame to identify the sha1sum of the commit that +added the functionality you want to backport. At times though such +functionality may have not been introduced via that commit but instead +it may have simply been moved from one place to another. You can use:: + + git blame sha1sum~1 + +to review if the functionality was present before the last commit you identified added that functionality to a file. + +Using git describe to identify where an commit was introduced +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Once you have identified the commit that introduced a specific +functionality you can use git describe --contains sha1sum to give you +the first commit tag that contains the commit. You can use the base of +the tag to help you figure out the first kernel release that added the +commit. + +For example, commit 600715dcdf567c86f8b2c6173fcfb4b873e25a19, or short, +600715dc added to the Linux kernel the CONFIG_PHYS_ADDR_T_64BIT feature. +We can determine that it was added on the v2.6.28 release by reviewing +the results of using:: + + git describe --contains 600715dc + +which yields: v2.6.28-rc1~271^2^4~6. This means that in order to +backport 600715dc we can edit two files on compat: + +- include/linux/compat-2.6.28.h +- compat/compat-2.6.28.c + +Since this functionality can be dealt with header files the c file is +not touched to backport this functionality. You can review the +respective `compat CONFIG_PHYS_ADDR_T_64BIT backport via gitweb +<https://github.com/mcgrof/compat/commit/4ec0edbd1cc2e6165e29f8ba466324e975e1cd73#include>`__. + +Testing across kernels +---------------------- + +The goal behind compat is to add features to provide backport but to +older kernels but to do this successfully we must also ensure that each +new patch added does not break building against a supported kernel. It +may be a daunting task to get all supported kernels to and also to build +against then, which is why we have started adding support to do all of +this for you. Under the bin/ directory you will find two scripts which +we document below: + +- get-compat-kernels +- ckmake + +get-compat-kernels +~~~~~~~~~~~~~~~~~~ + +You can run this script to install all known supported kernels. +Currently this will only work for Ubuntu, but `work is being considered +<https://lkml.org/lkml/2012/2/6/85>`__ to standardize on the same +kernels for any Linux distribution. + +ckmake +~~~~~~ + +You can run this to test compiling compat against supported kernels +available. Although initially designed to support Ubuntu only the goal +is to make this Linux distribution agnostic. + +compat modules +-------------- + +compat.git provides a few modules and headers to help with general +kernel compatibility. + +compat module +~~~~~~~~~~~~~ + +Provides all exported symbols implemented in each respective kernel +compat-2.6.xy.c files. Upon module load it just initializes the Linux +kernel's *power management Quality Of Service* (aka **pm-qos**) +Interface interface added as of the 2.6.24 kernel. No other things are +initialized, the rest of the compat module just acts as a library of +exported symbols. + +compat_firmware_class module +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Another module which compat.git provides is a backport of the +firmware_class module which got updated recently newer with a new +request_firmware_nowait() to allow better asynchronous firmware +uploading. This was added as of the 2.6.33 kernel. The firmware_class +module has been backported into a new module called +compat_firmware_class. A separate module has been defined instead of a +direct replacement for firmware_class since your system may have old +drivers which use the old request_firmware_nowait() and would bust if +they used the new request_firmware_nowait(). The compat_firmware_class +module registers its own sysfs subsystem and as such also gets udev +events sent through a separate subsystem. Because of this a new udev +rules file is required and provided. + +Research +-------- + +Active research is ongoing which could enhance automatically backporting +the Linux kernel further. For details please read up on: + +- `Jesper Andersen & Julia L. Lawall - Generic Patch Inference <http://www.diku.dk/~julia/andersen_ase08.pdf>`__ +- `Coccinelle spatch <http://coccinelle.lip6.fr/>`__ + +Consider one set of diffs that can be read by spdiff to produce an +spatch. This could in theory allow us to backport all functionality on a +kernel if only two or three sets of files were patched and interpreted +by spdiff. + +Contributions +------------- + +Contributions to compat follow the same mechanisms as used in the Linux +kernel, this means you should provide as Singed-off-by tag as documented +on the `Developer's Certificate of Origin 1.1 +<http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html>`__. + +Submitting patches +------------------ + +compat and compat-drivers contributions follow the contribution model +implemented by the Linux kernel. Patches or pull requests for compat and +compat-drivers must have be signed-offed. If you don't sign off on them +they will not accepted. This means adding a line that says +"Signed-off-by: Name email" at the end of each commit, indicating that +you wrote the code and have the right to pass it on as an open source +patch. For exact definition of what the Signed-off-by tag is you can +read the definition of the "Developer's Certificate of Origin 1.1", +which you can read here: + +http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html + +You can send patches as follows:: + + To: mcgrof@kernel.org + Cc: backports@vger.kernel.org + Subject: compat: foo + +License +------- + +The compat module and code is all licensed under the same license as the +Linux kernel and is considered a complete derivative work of the Linux +kernel. For more information refer to the COPYRIGHT file. diff --git a/source/documentation/integration.rst b/source/documentation/integration.rst new file mode 100644 index 0000000..f6c4dac --- /dev/null +++ b/source/documentation/integration.rst @@ -0,0 +1,247 @@ +Documentation/integration +========================= + +The backports project first started out by supporting making releases as +`packaged tarballs <Documentation/packaging>`__ whereby users can +compile future versions of device drivers on older versions of Linux. As +of tag backports-20141114 (first release branch will be based on +origin/linux-3.19.y) backports supports **kernel integration** support. + +Kernel integration support allows you to: + +- **atomically integrate** future versions of device drivers +- apply required patches to backport them +- add hooks into kconfig to make them visible and usable +- deal with conflicts with older versions of these same drivers + +By supporting kernel integration, the backports project can now support +enabling use of automatically backported subsystems and drivers on older +kernels without requiring modules, everything can be **built-in**. + +Kernel integration summary +-------------------------- + +In order to understand how kernel integration works familiarize yourself +first :doc:`the backports development flow <backports/hacking>` and +:doc:`the backports git tags and branches <backports/hacking>`. +Usage of integration involves a *kernel source* and *kernel target*. As +with :doc:`backports packaging <packaging>` each tag has a +respective upstream linux-next or linux stable respective tag which can +be used as a *kernel source*. The *kernel target* is a kernel tree of an +older Linux release. For example if you want to integrate linux-next tag +next-20141114 onto v3.15 you may want will want to use the tag +backports-20141114 on the backports tree; the *kernel source* will be +the linux-next tree tag next-20141114 (you can either reset the tree to +that tag or use --git-revision tag to ./gentree.py) and the *kernel +target* can be a linux git tree reset to the v3.15 tag. Each backports +tag should be usable on all older supported kernels, this means you +could have used as a *kernel target* a tree set to v3.0, v3.1.. up to +today's latest release. + +Kernel integration use case +--------------------------- + +**Kernel integration** is an advanced technique part of the backports +project which should make automate the task of completely integrating a +specific version of a device driver based on future / current upstream +releases on older kernel trees. This is typically more important where +products are being supported using old kernels but the required device +driver is only available on a future version of Linux. Linux +distributions which want to make releases based on slightly older +version of Linux but need newer device drivers can also make use of +this. Kernel integration support enables two new important features when +using backports now: + +- built-in support (non modular) +- support for backporting features / components which the kernel only + supported via built-in + +*How you use integration is up to you*, we provide tools to help with +the process and at least for now **make the first integration +seamless**. If you are resetting your tree every time you base your +release on a new version of Linux you can use kernel integration to bump +the supported device drivers up to the latest known stable release for +example, thereby minimizing the amount of manual cherry picks required. +The backports project only provides patches required to backport device +drivers from a future version of Linux down to a specific release of +Linux, although it does not maintain specific cherry picks outside of +what is required to get the driver to work on older versions of Linux +specific cherry picks can easily be aggregated on top of the carried set +of patches. Use of backports for cherry picking it outside of the scope +of support for the project but it simply consists of adding your patches +onto the patches/ directory, either in legacy patch form or SmPL form, +if this strategy is followed its recommended a new directory be used to +track these patches and a way to know if they need to be carried over +when moving to a new version of Linux / backports. + +Integrating a release +--------------------- + +The same script that is used for generating :doc:`backports packaged +tarballs <packaging>` is used for kernel integration, gentree.py as +there is a lot of code to share between both strategies. An example will +be provided of how to integrate a future set of supported device drivers +onto an older release tree of the Linux kernel. Any kernel tree >= 3.0 +can be used as a *kernel target*, the *kernel source* will be any tag +after next-20141114 from linux-next and backports-20141114, as well as +any Linux release after v3.19 using the respective backports stable +branch for that release. The example we provide here integrates +linux-next next-20141114 onto the Linux kernel tree reset to v3.15. + +To backport linux-next tag next-20141114 onto a Linux tree reset to +v3.15 do, you must first ensure your backports tree is on +backports-20141114 and then you can use:: + + $./gentree.py --integrate --clean --gitdebug --git-revision next-20141114 ~/linux-next/ ~/linux/ + +This assumes that ~/linux/ is a git tree reset to the tag v3.15. This +should take 1-2 minutes on a typical laptop / system. + +Kernel integration menuconfig +----------------------------- + +After kernel integration you will see an entry like the one that follows +on your 'make menuconfig' menu:: + + [*] Backport Linux next-20141114-0-gd7e5a72 (backports backports-20141114-0-gded96b2) ---> + +.. image:: ../media/integration-menuconfig-start-3.15.png + +Under that menu you will see device drivers taken from linux-next tag +next-20141114 and backported for you for use on v3.15. Enabling one +device driver from a future version of Linux will require using only the +latest version of the subsystem modules and other subsystem drivers. For +example enabling cfg80211 and mac80211 from a future version of Linux +will require you to only use future version of the respective device +drivers. In order to enable the backported version of 802.11 drivers for +example, you will have to enable first:: + + Networking support --> + Wireless --> + +But under that menu disable all options. You will also need to now +disable all 802.11 device drivers under (including CONFIG_WLAN):: + + Device Drivers ---> + Network device support ---> + [ ] Wireless LAN ----> + +Now to enable 802.11 drivers jump to the backports submenu to now enable +backported 802.11 drivers:: + + Backports --> + cfg80211 + mac80211 + Wireless LAN ---> + etc + +You should now be able to enable any backports 802.11 device driver. +Here's an example of full list of things you should see as of +backports-20141114:: + +.. figure:: Integration-menuconfig-drivers-3.15.png + +Audit kernel integration work +----------------------------- + +Backports takes advantage of the previously supported --gitdebug flag +for backport packaging in order to allow atomically tracking each atomic +operation done when integrating all pieces of software from a future +kernel to be supported on the *target kernel*. For this particular +integration, for example, it generates 92 commits. Ordered with the last +commit first, these are:: + + $ git log v3.15~1.. --pretty=oneline + c066a39ad047947dafbc4418ff10dadd3ad07921 apply integration patch 001-enable-backports/0001-enable-backports-built-in.patch + 000658cb018b781a08f174df3b5521b4385de759 hooked backport to top level Kconfig + d78c278758a81a16d5f7d3dfd0782600cf5376ed disable unsatisfied Makefile parts + e9d0f1fbfa6ce67feb1cff978bca40875277c47f add kernel version dependencies + f5b738e65019fd51201688e3080d71c9ad5e8477 disable impossible kconfig symbols + 7de02203cd5a501bd69ea6c98eac126f1eb57b61 rename config symbol / srctree usage + f70c7f185ca87d2f52ad72732fda3f1fa70f0891 add (useful) defconfig files + 697ece5caa7e38f3ef34811b4440637c6d8fa080 convert select to depends on + 9bf64ce6127ef2abfa2463b1063a236863e14f7b adjust backports config symbols we port + b42e104c94ab0d30967dc5a31062335370b10a4f prune Kconfig tree + b52feb5fef8a887170eee04383e1986a153dccd9 verify sources on top level backports Kconfig + 61d328ea565d3f03573b3a99dd3f3896efef727b generate kernel version requirement Kconfig file + 900a22cca078a7a5793d7c3b2bb444066677539a apply backport SmPL patch collateral-evolutions/network/0031-sk_data_ready.cocci + ef6d48763eb52f65bcd0eabfd8ae9e9f16e5074f apply backport SmPL patch collateral-evolutions/network/0019-usb_driver_lpm.cocci + f14786714aff5c94ae49b6f0acc3af095f5fbf5f apply backport SmPL patch collateral-evolutions/network/0001-netlink-portid.cocci + 9f88ec9628756758132fe7c189c82575127ed838 apply backport SmPL patch collateral-evolutions/generic/0001-group-attr/0002-group_attr_bus.cocci + 93b0c05507001c338a4efc4d9f3699bfee286b85 apply backport SmPL patch collateral-evolutions/generic/0001-group-attr/0001-group_attr_class.cocci + be4fb7cdd961f3d336086253712381190d7f8316 apply backport patch collateral-evolutions/network/0049-no-pfmemalloc/igb.patch + d048c6abbaa4a17eeed64b75bf071dd83e575959 apply backport patch collateral-evolutions/network/0048-no_ndo_xmit_flush/igb.patch + c606a1727efa4fb0aaddb103fc0ace9e7340110d apply backport patch collateral-evolutions/network/0047-write_iter/bluetooth.patch + 09a99346f1625aa0ce203de1134145be750d6dc7 apply backport patch collateral-evolutions/network/0046-mmc_rescan_entered/mwifiex.patch + 9fb5b3de864d7fa049ff0e304e2c04931351adbd apply backport patch collateral-evolutions/network/0044-no_user_ns_in_net/ieee802154.patch + a79ce2806e10dc7ac13c0f0f00b43e08454a8c29 apply backport patch collateral-evolutions/network/0043-ndo_set_vf_rate/igb.patch + 01de0cf6c40dae21404e5fcf0f0e622a7cc4364c apply backport patch collateral-evolutions/network/0042-pci_error_handlers/ngene.patch + f6a578dd6050dfb76b0c9e79b6e7e9fc1539697f apply backport patch collateral-evolutions/network/0042-pci_error_handlers/igb_pci_error_handlers.patch + 69c972277125ce73ca22d5436311c5718449669d apply backport patch collateral-evolutions/network/0042-pci_error_handlers/atl1e.patch + 87664cd587c14623c386ac583f7dfebedfd07469 apply backport patch collateral-evolutions/network/0042-pci_error_handlers/atl1c.patch + 102f85e8d0b698528bd05adb1fad73004330ca9e apply backport patch collateral-evolutions/network/0042-pci_error_handlers/alx.patch + 807d99b29a7186a398a3895df8c22911a46c5686 apply backport patch collateral-evolutions/network/0041-devm_hwmon_device_register_with_groups/igb-devm_hwmon_device_register_with_groups.patch + 5e399498c589af4f144a78590d6303bada824183 apply backport patch collateral-evolutions/network/0040-ethtool_cmd_mdix/igb_ethtool_cmd_mdix.patch + 041bb3abc060f04b0924e2c313479430257a0b8a apply backport patch collateral-evolutions/network/0039-ethtool_rxnfc/igb_rxnfc.patch + 91bc49e12a2c302eb6e264eeb6944806caaa2714 apply backport patch collateral-evolutions/network/0038-ethtool_rxfh_indir/igb_rxfh_indir.patch + 24fe54661213f4d82642dd7eaeae92314ee2ca55 apply backport patch collateral-evolutions/network/0037-ethtool_get_module/igb_get_module.patch + 5a8c3bf1e10a9dcd31f50c3acd3a42d6a4a5b3ac apply backport patch collateral-evolutions/network/0036-ethtool_eee/igb_ethtool_eee.patch + 237294691d58ec7ff6e41fc6f48587bd7d6c1f7c apply backport patch collateral-evolutions/network/0035-skb_no_fcs/igb_skb_no_fcs.patch + fb1cb2e44c89847b04e2d021328ea548cbe05fa6 apply backport patch collateral-evolutions/network/0034-ndo_set_vf_spoofchk/igb_ndo_set_vf_spoofchk.patch + f24bb572ee690b3aac0e89fa2d04888e8a036d7c apply backport patch collateral-evolutions/network/0033-ndo_vlan_rx_vid/igb_ndo_vlan_rx_vid.patch + 3878c64fc254f7acbd86e3539bf330b04730abb8 apply backport patch collateral-evolutions/network/0033-ndo_vlan_rx_vid/cdc_mbim.patch + c888e6433a8b2ac7c3e0058a4936836ab15c3f6d apply backport patch collateral-evolutions/network/0032-sriov_configure/igb_sriov_configure.patch + 59ac89cb5e1fa8876555639bab09bc4a97673db5 apply backport patch collateral-evolutions/network/0030-qdisc_tx_busylock/ieee802154.patch + 506736ea6f59fed1d323f77cf03915ebc6df3358 apply backport patch collateral-evolutions/network/0030-qdisc_tx_busylock/bluetooth.patch + 5131db4cbec4ac8d7a6fb69246910644e0a8087d apply backport patch collateral-evolutions/network/0029-struct_hid_ll_driver-extensions/net_bluetooth_hidp_core.patch + 9575c214edcc921e75910b881d3db6a69cd4b577 apply backport patch collateral-evolutions/network/0028-select_queue/mwifiex.patch + eafd9157010633a1cc7b025382b72f9bea8bfe8b apply backport patch collateral-evolutions/network/0028-select_queue/mac80211.patch + 4b7d5be3639ec2178a398c6a0730a8a9098f067e apply backport patch collateral-evolutions/network/0027-genl-const/nl80211.patch + 2283432684181d75e6288b2bd4d9f502c713087d apply backport patch collateral-evolutions/network/0027-genl-const/nfc.patch + e5fec49c6b5c59dffe06f11a099e8df2c38de2cd apply backport patch collateral-evolutions/network/0027-genl-const/ieee802154.patch + 7b0bd1c47c0a22240593c3860ea78e87310531db apply backport patch collateral-evolutions/network/0027-genl-const/hwsim.patch + 3156a48fc2aa1eb028d5074d0f15f02a2a784366 apply backport patch collateral-evolutions/network/0026-ipv6_stub/cdc_mbim.patch + ab5ca0e7db55e7a68bae27c278dc159be531caf7 apply backport patch collateral-evolutions/network/0025-usb-sg/usbnet.patch + 18634861a944029a6623f5dc582482d7fdd87bba apply backport patch collateral-evolutions/network/0024-led-blink-api/mac80211.patch + 6895c3c9fefe90302577ccc0207e574dab5db4fb apply backport patch collateral-evolutions/network/0022-define-tracing/wil6210.patch + 61b12eb789add8ea4f42343ba5754a2003f9ff85 apply backport patch collateral-evolutions/network/0022-define-tracing/cfg80211.patch + 4d362e9144e6189248976e83b797e93b5be2210a apply backport patch collateral-evolutions/network/0022-define-tracing/ath6kl.patch + a7a3cebf434a294ef089823eedf7c2db8b41a042 apply backport patch collateral-evolutions/network/0021-umode_t-api-change/ath10k.patch + a25e701fe08b1f124307c17cfa1eb1879b26693d apply backport patch collateral-evolutions/network/0020-tty-termios/net_bluetooth_rfcomm_tty.patch + 829c2477a533e03c8df4f64d60d3acbc260f2090 apply backport patch collateral-evolutions/network/0020-tty-termios/drivers_bluetooth_hci_ath.patch + 4793ad2d27a5a98b99f1af0cc4369f4d2dc67a78 apply backport patch collateral-evolutions/network/0018-pv-trace-fixes/net_mac80211_trace.patch + cc3fcdfcd106be170937111f5b1e9282ea8b2f43 apply backport patch collateral-evolutions/network/0018-pv-trace-fixes/drivers_net_wireless_iwlwifi_iwl-debug.patch + 77b4d3a92296542ada9af173729c29ff8edaa4f0 apply backport patch collateral-evolutions/network/0017-get_ts_info/igb_get_ts_info.patch + 3a1b78fee0ed903f167f2038ce3f7b34b80fff31 apply backport patch collateral-evolutions/network/0017-get_ts_info/drivers_net_usb_usbnet.patch + 7af04292e12cd6a3bd4933cbc2db33f678935985 apply backport patch collateral-evolutions/network/0017-get_ts_info/cdc_ncm.patch + c9c75a56434fa88c3b5387964d390c957109bb0e apply backport patch collateral-evolutions/network/0016-libertas-olpc-ec-wakeup/drivers_net_wireless_libertas_if_usb.patch + 63959daeafbac9ff38dbc847cbbb9a61501be851 apply backport patch collateral-evolutions/network/0015-rename_pm_qos_request/drivers_net_wireless_ipw2x00_ipw2100.patch + 5e7f8f9b32dcb984445bde43f69656c97b31c7e7 apply backport patch collateral-evolutions/network/0014-netlink_seq/net_wireless_nl80211.patch + 35d5785bfdcdf579493f3076f3ac9bc397ce9597 apply backport patch collateral-evolutions/network/0013-fix-makefile-includes/net_wireless_Makefile.patch + 5adbb25691d4745f5f47ffc493bfd32a063480ca apply backport patch collateral-evolutions/network/0013-fix-makefile-includes/bluetooth.patch + 2258d123aec87c0a11515130d9297587633fdafc apply backport patch collateral-evolutions/network/0012-driver-quirks/drivers_net_wireless_cw1200_sdio.patch + d1f6fc792d3fba9ee20f31562c04e34af0f6daab apply backport patch collateral-evolutions/network/0011-mac80211-disable-tx-status/net_mac80211_tx.patch + a146dcd4c0db925dc8a3fec1ee93074b0a192c67 apply backport patch collateral-evolutions/network/0010-add-wext-handlers-to-netdev/net_wireless_core.patch + 5e1b6f56f043608ee68cef35d7deda383b78fd01 apply backport patch collateral-evolutions/network/0008-net-user-ns.patch + 5000b38d3dcc9434b19eaccde8aca21f0b271e12 apply backport patch collateral-evolutions/network/0007-lowpan-inet_frag_lru_move.patch + 2ae7bbbdb7eb2c02058327dfc057ad841aede913 apply backport patch collateral-evolutions/network/0006-ieee802154-6lowpan-namespace.patch + fc28048373ae3c6637cedab606919e7817f6ffad apply backport patch collateral-evolutions/network/0005-disable-usb-net-asix.patch + 50e3e5f2151ed76aef9a1ac7352959a806e55e6f apply backport patch collateral-evolutions/network/0004-disable-wext-kconfig.patch + 98b551a9316154702270ac7164916e49180c0046 apply backport patch collateral-evolutions/network/0003-cfg80211-wext-padding/net_wireless_core.patch + 0f5f1ae4483b16f187f074b676d19212dab814f8 apply backport patch collateral-evolutions/network/0003-cfg80211-wext-padding/include_net_cfg80211.patch + 8cfeb3d0bdec62cccb0cf76f44ca2e7e5c5e9ff0 apply backport patch collateral-evolutions/network/0002-disable-dump-adjust-on-old-kernels.patch + 166003e19c7a9ff28a43004ad27d68af3a3aace0 apply backport patch collateral-evolutions/media/0004-missing-include/ir-hix5hd2.patch + f1152ca58d2400a956a969ae88b80c35c449d6dc apply backport patch collateral-evolutions/media/0004-missing-include/hackrf.patch + 94f80b0f595162569b70684d7ed87612b31a764f apply backport patch collateral-evolutions/media/0004-missing-include/airspy.patch + 6d974050060a1d74d61b1927ac0f18ca0267e3d5 apply backport patch collateral-evolutions/media/0003-devnode_param_type/rc.patch + 2678364bc96c15c9e39bdf901f60fb8bef5d9851 apply backport patch collateral-evolutions/media/0003-devnode_param_type/dvb-core.patch + 04361b3134ed2cd078920eb651ec1a15c038a307 apply backport patch collateral-evolutions/media/0003-devnode_param_type/ddbridge.patch + b0a68f9e7b235ad44f64686a7657d65ededaeb87 apply backport patch collateral-evolutions/media/0002-no_dmabuf/v4l2.patch + 102162ef4bda228fc2de08826f8c304001503b67 apply backport patch collateral-evolutions/media/0001-dma_mmap_coherent-revert.patch + 780d84bd410b4252cfc4df431b5c0e8c6133fcef apply backport patch 0000-upstream-backport-changes/0005-uapi-compromise/mwifiex.patch + 6a77c4dc3c16907373648a774678c0bf63b1f786 Add automatic backports + 6e8820dfdd11eb2ef361f344ece8170e6776a151 modify top level backports/Kconfig with backports identity + c1e39709cfde12068fa3b693d71f72fc536d4df4 verify sources for automatic backports + 9b34df472df8dbf0c3b518eab7a5e378c966fa3f Add driver sources + 5b8285fa632ad085753da8e930c0ec2275c191ff Copied backport + 1860e379875dfe7271c649058aeddffe5afd9d0d Linux 3.15 diff --git a/source/documentation/packaging.rst b/source/documentation/packaging.rst new file mode 100644 index 0000000..2f3921e --- /dev/null +++ b/source/documentation/packaging.rst @@ -0,0 +1,99 @@ +Documentation/packaging +======================= + +The backports project makes release of two types of **packages** which +provides device drivers from future versions of Linux usable on older +Linux kernel releases. + +Backports package release types +------------------------------- + +Both daily snapshots based on `linux-next +<http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git>`__, +and stable releases based `Linux's stable releases +<http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git>`__ +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. + +Usage guide +----------- + +Building backports follows the same build mechanism as building the +Linux kernel:: + + # as a user + make menuconfig + make -j4 + # as root + make install + # reboot and enjoy + +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:: + + make help + make defconfig-help + +If you use this option just use the 'make defconf-option' in replacement +for *make menuconfig* above. For example to compile all wifi drivers:: + + # as a user + make defconfig-wifi + make -j4 + # as root + make install + +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). + +Cross compiling +--------------- + +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. + +Cross compile with Freescale's LTIB +----------------------------------- + +To get backports happy in LTIB, use UNSPOOF/SPOOF_PATH to switch between +host and cross environment. Example Build 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 diff --git a/source/index.rst b/source/index.rst new file mode 100644 index 0000000..a90daf3 --- /dev/null +++ b/source/index.rst @@ -0,0 +1,73 @@ +Backports +========= + +The *Backports Project* enables old kernels to run the latest drivers. + +"*Backporting*" is the process of making new software run on something +old. A version of something new that's been modified to run on something +old is called a "*backport*". + +The Backports Project develops tools to automate the backporting process +for Linux drivers. These tools form the *backports* suite. + +History +------- + +The Backports Project started in 2007 as *compat-wireless*. It was +renamed to *compat-drivers* as the project's scope broadened beyond just +wireless network drivers. Nowadays, the project is known simply as +*backports*. + +As of the 3.10-based release, over 830 device drivers had been +backported. + +Recent versions of backports support mainline kernels back to version +3.0. The older backports-3.14 supports all kernel versions back to +version 2.6.26. + +.. toctree:: + :maxdepth: 1 + + Package releases: (download) <releases> + Documentation <documentation> + Reporting bugs & security vulnerabilities <bugs> + code + config-brainstorming + Contributing <documentation/backports/hacking> + Linux kernel backports license <license> + Mailing list <mailing_list> + IRC <irc> + Social Media <social_media> + Meetings <meetings> + +Resources +--------- + +- Daily snapshots: `(linux-next) + <http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git>`__ + `(linux-stable) + <http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git>`__ + +- `git repository + <https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git>`__ + +- `Bugzilla bug tracker: + <https://bugzilla.kernel.org/enter_bug.cgi?product=Backports%20project>`__ + :doc:`(notes) <bugs>` + +- `Increasing Automation in the Backporting of Linux Drivers Using + Coccinelle - Luis R. Rodriguez, Julia Lawall + <http://coccinelle.lip6.fr/papers/backport_edcc15.pdf>`__ (12 pages) + +- `Automatically Backporting the Linux Kernel - Luis Rodriguez + <https://www.youtube.com/watch?v=ZXATzae7eng>`__ (54 minutes), SUSE + Labs Conference, České Budějovice, October 2014 + +- `An Introduction to Coccinelle Bug Finding and Code Evolution for the + Linux Kernel - Julia Lawall + <https://www.youtube.com/watch?v=buZrNd6XkEw>`__ (1 hour 58 minutes), + SUSE Labs Conference, České Budějovice, October 2014 + +- `An Update on the Linux Backports Project - Luis R. Rodriguez, + Qualcomm Atheros <https://www.youtube.com/watch?v=lvFXQ6zyHCg>`__ (43 + minutes), LinuxCon and CloudOpen Conference, New Orleans, October 2013 diff --git a/source/irc.rst b/source/irc.rst new file mode 100644 index 0000000..3d815c5 --- /dev/null +++ b/source/irc.rst @@ -0,0 +1,9 @@ +IRC +=== + +Join us:: + + irc.freenode.net #kernel-backports + +Do not ask for permission to ask a question in IRC, just ask it with all +the information you have and wait for someone answering. diff --git a/source/license.rst b/source/license.rst new file mode 100644 index 0000000..6a1f7b0 --- /dev/null +++ b/source/license.rst @@ -0,0 +1,30 @@ +License +======= + +Linux kernel backports license +------------------------------ + +This work is a subset of the Linux kernel as such we keep the kernel's +Copyright practice. Some files have their own copyright and in those +cases the license is mentioned in the file. All additional work made to +building this package is licensed under the GPLv2. + +Backporting preference for EXPORT_SYMBOL_GPL() and proprietary drivers +---------------------------------------------------------------------- + +The Linux kernel backports framework was designed by intent since its +inception \*only\* for upstream Linux kernel drivers to avoid excuses +about the difficulty to support upstream Linux kernel development while +also supporting users on older kernels. To ensure the intent is +respected currently all symbols that we do work on to backport are +exported via EXPORT_SYMBOL_GPL() as we do work to backport them for the +supported kernels. By using EXPORT_SYMBOL_GPL() we make it \*clear\* +that if you use the backported symbols your software \*is\* considered +derivative works of the Linux kernel. + +Developer's Certificate of Origin 1.1 +------------------------------------- + +Linux backports relies on the 'Developer's Certificate of Origin 1.1', +for more details refer to :doc:`the submitting patches documentation +<documentation/backports/hacking>`. diff --git a/source/mailing_list.rst b/source/mailing_list.rst new file mode 100644 index 0000000..2fd647b --- /dev/null +++ b/source/mailing_list.rst @@ -0,0 +1,14 @@ +Mailing list +============ + +- backports@vger.kernel.org `(archives) <https://lore.kernel.org/backports>`__ +- `Subscribing <https://subspace.kernel.org/subscribing.html>`__ + +Topics +------ + +Contact the backports@vger.kernel.org mailing list with: + +- patches +- bug reports +- questions regarding the backports project diff --git a/source/media/integration-menuconfig-start-3.15.png b/source/media/integration-menuconfig-start-3.15.png Binary files differnew file mode 100644 index 0000000..a40c620 --- /dev/null +++ b/source/media/integration-menuconfig-start-3.15.png diff --git a/source/meetings.rst b/source/meetings.rst new file mode 100644 index 0000000..7a1e5f2 --- /dev/null +++ b/source/meetings.rst @@ -0,0 +1,53 @@ +Meetings +======== + +Backport project meetings +------------------------- + +At times we may meet. This page is dedicated towards documenting any +meetings that have taken place or will take place. + +Linux Plumbers 2013 - New Orleans +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +There will be a talk about backporting at LPC 2013. + +Sept 4 2012 meeting +~~~~~~~~~~~~~~~~~~~ + +On Sept 4, 2012 we had our first `G+ Linux kernel backports hangout +<https://plus.google.com/events/cbsid8cbvp61sv4nmjfgftsv9f0/101487746899672598413>`__ +at. This took place at: + +- 08:00:00 p.m. Tuesday September 4, 2012 in GMT +- 01:00:00 p.m. Tuesday September 4, 2012 in US/Pacific +- 04:00:00 p.m. Tuesday September 4, 2012 in US/Eastern +- 10:00:00 p.m. Tuesday September 4, 2012 in Europe/Berlin +- 11:00:00 p.m. Tuesday September 4, 2012 in Europe/Helsinki +- 11:00:00 p.m. Tuesday September 4, 2012 in Asia/Jerusalem +- 01:30:00 a.m. Wednesday September 5, 2012 in Asia/Calcutta + +Recording of the session: + +http://www.youtube.com/watch?v=FZqDz7sXZiQ + +Agenda: + +- Current project objectives: + + - 802.11, Bluetooth, Ethernet, drm drivers + - Vanilla kernels are supported but also now: + + - RHEL6 + + - Coccinelle SmPL - 0001-netdev_ops.patch -- collateral evolution work + - Build server for helping with testing patches + - git tree mirroring on git.kernel.org + - Daily linux-next based snapshots via kernel.org + - Public facing releases via kernel.org as of v3.7-rc1 + +- Things to look out for: + + - linux-firmware.git updates - script install target ? + - Module key signing & UEFI - Fedora 18 Alpha release schedule for 2012-09-11 + - Understanding the implications of a stable extra version release update: ee9c8a04 backported to v3.4.6 diff --git a/source/releases.rst b/source/releases.rst new file mode 100644 index 0000000..5559f7c --- /dev/null +++ b/source/releases.rst @@ -0,0 +1,88 @@ +Releases +======== + +Latest releases +=============== + +All these releases should work against the same kernel major version and +all older versions till 3.10 for backports versions till 5.10. Later +versions of backprots should work with kernel versions down to version +4.4. + +- `backports-6.1.97-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v6.1.97/backports-6.1.97-1.tar.xz>`__ + + - SHA256: 8e9ae2d02f373252dd61f5c6a81c88eec67ca773464d9ef3d844752dc6775540 + +- `backports-5.15.153-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.15.153/backports-5.15.153-1.tar.xz>`__ + + - SHA256: eaa24df968c79385c57707068a209fb1ea43271b573f24885805ae96a58ee3a8 + +- `backports-5.14.13-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.14.13/backports-5.14.13-1.tar.xz>`__ + + - SHA256: 042aef20caf17ef649502d5f2e744a7676abe7faed18de83c96f37bc029635fe + +- `backports-5.13.19-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.13.19/backports-5.13.19-1.tar.xz>`__ + + - SHA256: 1eb761c1664d59a0a2d52847f240c9d02fc2e56fb27d862d2949bfb275187eef + +- `backports-5.12.19-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.12.19/backports-5.12.19-1.tar.xz>`__ + + - SHA256: 4233002bcf26237783cd517d93c27807e534234cef64def7e550c5f06b779d18 + +- `backports-5.11.22-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.11.22/backports-5.11.22-1.tar.xz>`__ + + - SHA256: 35c23dd182711a3a6f671a673c2e0ace2ffdd25bbd1fb917e428d04924141299 + +- `backports-5.10.157-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.10.157/backports-5.10.157-1.tar.xz>`__ + + - SHA256: 1ce937c49f2b39be00768fba83e214aad6612d469c92ccd06dc17b14e6cf3a64 + +- `backports-5.9.12-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.9.12/backports-5.9.12-1.tar.xz>`__ + + - SHA256: 8cf3f23152a787eeec2df1d7b38a559b0d89bdc823d9ac99175a4eb76d2b619e + +- `backports-5.8.18-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.8.18/backports-5.8.18-1.tar.xz>`__ + + - SHA256: f04a8172423c6a945fc7d9844b04f33fda9ae574e552f8f18ee3bdfcfb494563 + +- `backports-5.7.5-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.7.5/backports-5.7.5-1.tar.xz>`__ + + - SHA256: 200312d46eb6a94676f611af6baebbffc5cbf3b7dd75e72a69c767704c37b571 + +- `backports-5.6.8-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.6.8/backports-5.6.8-1.tar.xz>`__ + + - SHA256: 547c5e17b9e23dd23cdf4d617a7550b80869e02114a7d404911c5ae928ae1da5 + +- `backports-5.5.19-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.5.19/backports-5.5.19-1.tar.xz>`__ + + - SHA256: 9dd9153df6082eaa079144193a3fab79d200942e1a2a1a80e032c9667b7b92a6 + +- `backports-5.4.56-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.4.56/backports-5.4.56-1.tar.xz>`__ + + - SHA256: 6030c2427e04f976cf53330087d0fdbb60ead7e1fecbd85e6f8e97ec0ed9a2eb + +- `backports-5.3.6-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.3.6/backports-5.3.6-1.tar.xz>`__ + + - SHA256: 16ded706945999543a73e2349d36b8003eeb2b097970ea1ad80344b9f56393a3 + +- `backports-5.2.8-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.2.8/backports-5.2.8-1.tar.xz>`__ + + - SHA256: d1ac22a9b7536f730a992292fb29c70355ffc42ea9f58610010ea196dc69b2e3 + +- `backports-5.1.16-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.1.16/backports-5.1.16-1.tar.xz>`__ + + - SHA256: b5adc5d458734b9231e81bcf03af2fb1bf2e289a87f1551a4f02bdf3ba053fb8 + +- `backports-5.0.5-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.0.5/backports-5.0.5-1.tar.xz>`__ + + - SHA256: 9fe6eeaf2043a6eadbc5a13277b0ac62905451af55d7afaa6ac2d91a3aa8c298 + +- `backports-4.20.17-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v4.20.17/backports-4.20.17-1.tar.xz>`__ + + - SHA256: c7efc87babef35c08251a04cb26ffd683026d1365f5bbf8226c9e22462c41592 + +- `backports-4.19.221-1.tar.xz <https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v4.19.221/backports-4.19.221-1.tar.xz>`__ + + - SHA256: 343f54b21ddda4bc79c0457a7fa88356d430b802f86194abc20fe09c12559b05 + +All releases: https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/ diff --git a/source/social_media.rst b/source/social_media.rst new file mode 100644 index 0000000..88a6761 --- /dev/null +++ b/source/social_media.rst @@ -0,0 +1,11 @@ +Social media +============ + +Linux backports social media +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Apart from making announcements on the mailing lists you can also +subscribe to the following social media outlets to get updates: + +- `@LinuxBackports on Twitter <https://twitter.com/LinuxBackports>`__ +- `@LinuxBackports on identi.ca <http://identi.ca/linuxbackports>`__ diff --git a/wiki/Bugs.mediawiki b/wiki/Bugs.mediawiki deleted file mode 100644 index 0dd8542..0000000 --- a/wiki/Bugs.mediawiki +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Bugs ---- - -Report '''any bugs''' you '''think''' you '''may''' have found because you are working with the '''latest and greatest drivers'''! If your bug is backport compatibility-related then we should still try to fix it within the compatibility layer. If you are not sure you can let us help you. '''To date we have only have identified 2 backport related bugs''', all other reported bugs were '''real bugs''' in '''actual upstream''' code! - -We are working on a bugzilla entry for compat / compat-drivers, until then please report all bugs you think you my have found to the [[mailing_list|backports mailing list]] and if you know what subsystem you think the bug belongs to Cc: the respective mailing list. Remember that chances are '''high''' that the bug is not a backport bug but instead a real upstream bug that '''must''' be fixed. - -<h1>What mailing lists to report bugs to</h1> - -Always use: '''backports@vger.kernel.org''' and then use one of the following mailing lists depending on the subsystem from where your driver belongs: - - * bluetooth: linux-bluetooth@vger.kernel.org - * wireless: linux-wireless@vger.kernel.org - * ethernet: netdev@vger.kernel.org - -<h1>Reporting security vulnerabilities</h1> - -If you have a security vulnerabilities issue to report and you know it is backports related you can report this directly to the maintainers: - - * hauke@hauke-m.de, mcgrof@kernel.org, johannes@sipsolutions.net - -The report will be handled in private, once the issue is fixed and propagated to users, the security fix will be disclosed and documented. As of date we have had no security vulnerabilities issues reported. Until then this page can be used to track updates on vulnerabilities related to Linux backports. The attack surface to Linux backports consists about 1-2% of code, this varies depending on what kernel you are on. The older kernel you are on the higher the security risk. Security issues on Linux should affect users of Linux backports if the code is carried over into backports, fixes for that are addressed through new release of backports with the corresponding upstream fixes. Security fixes for Linux belong upstream on Linux, not on Linux backports. To learn how to report Linux kernel security issues refer to [https://www.kernel.org/doc/Documentation/SecurityBugs SecurityBugs documentation]. - -= Bugzilla = - -The Linux kernel bugzilla has an entry for backport bugs. - -== Reporting new backport bugs == - -To record a new bug: - -# access the [https://bugzilla.kernel.org/enter_bug.cgi?product=Backports%20project '''Backports project'''] section of Bugzilla -# select the ''backports'' component (it is the only component available) - -== Viewing bugs by status == - -* [https://bugzilla.kernel.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=Backports+project&content=. View open bugs] -* [https://bugzilla.kernel.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__closed__&product=Backports+project&content=. View closed bugs] - -[[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].
\ No newline at end of file diff --git a/wiki/Code.mediawiki b/wiki/Code.mediawiki deleted file mode 100644 index b50666a..0000000 --- a/wiki/Code.mediawiki +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Code ---- - -In order to backport the Linux kernel we must divide and conquer the tasks at hand. - -This is now deprecated use [[Documentation/backports/hacking|hacking on backports]]. -<h1>Backport components</h1> - -There are currently two components to the backports effort. - -<h2>compat</h2> - -compat is a shared module / headers that implements newer features for usage on older kernels. - - * [https://github.com/mcgrof/compat git://github.com/mcgrof/compat.git] [[compat|compat documentation]] - -<h2>compat-drivers</h2> - -compat-drivers is the framework that pulls code from the Linux kernel, adds the compat module and backports features that compat could not backport within its module / headers. - - * [https://github.com/mcgrof/compat-drivers git://github.com/mcgrof/compat-drivers.git] [[compat-drivers|compat-drivers documentation]] - -<h1>Getting all required code</h1> - -To be able to make releases and test building releases however you need quite a bit more code. The setup is simplified with scripts from the compat.git tree. To set your system up for the first time you can run: - -<code> -<pre> -wget https://github.com/mcgrof/compat/raw/master/bin/get-compat-trees -wget https://github.com/mcgrof/compat/raw/master/bin/get-compat-kernels - -chmod 755 get-compat-trees get-compat-kernels - -./get-compat-trees -./get-compat-kernels -</pre> -</code> - -<h1>Hacking on the project</h1> - -You should realize that there are a few components to the project and that although they are used together each one can be considered independent of each other. - - * Read the [[compat|hacking on compat documentation]]. - * Read the [[Hacking|hacking on compat-drivers documentation]]. - -<h2>TODO list</h2> - -Read the [[Hacking#TODO|hacking TODO]] for a list of wish items we should be working towards.
\ No newline at end of file diff --git a/wiki/Config-brainstorming.mediawiki b/wiki/Config-brainstorming.mediawiki deleted file mode 100644 index 6709ec8..0000000 --- a/wiki/Config-brainstorming.mediawiki +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: Config-brainstorming ---- - -Brainstorming for enable Kconfig on compat-drivers - -<h1>Step 1</h1> - -Using the existing kernel's config, generate a Kconfig file that contains all the right symbols for that kernel: - -<code> -<pre> -cat .config | genkconf.sh > kernel-kconfig -</pre> -</code> - -where the script is this: - -<code> -<pre> -#!/bin/bash - -while read line ; do - case "${line:0:7}" in - "CONFIG_") - line="${line:7}" - cfg="${line%%=*}" - val="${line#*=}" - cfgtype="skip" - if [ "$val" = "m" ] ; then - cfgtype="tristate" - elif [ "$val" = "y" ] ; then - cfgtype="bool" - fi - if [ "$cfgtype" != "skip" ] ; then - echo "config $cfg" - echo " $cfgtype" - echo " default $val" - echo "" - fi - ;; - "# CONFI") - cfg="${line:9}" - cfg="${cfg%% is not set}" - echo "config $cfg" - echo " bool" - echo " default n" - echo "" - ;; - esac -done -</pre> -</code> - -<h1>Step 2</h1> - -Collect all Kconfig symbols from compat: -<code> -<pre> -find . -name Kconfig | xargs cat | sed 's/^config //;t;d' > symbols -</pre> -</code> - -<h1>Step 3</h1> - -Instead of patching Makefiles, replaces all CONFIG_ by CONFIG_COMPAT_ in all Makefiles: - -<code><pre> -find . -name Makefile | xargs rpl "CONFIG_" "CONFIG_COMPAT_" -</pre></code> - -This means that only things that are actually selected in compat will be built. - -<h1>Step 4</h1> - -Replace all "FOO" with "COMPAT_FOO" symbols in Kconfig and code files: - -<code><pre> -for sym in $(cat symbols) ; do - find . -name Kconfig |\ - xargs rpl -w "$sym" "COMPAT_$sym" - - find . -name '*.c' -o -name '*.h' |\ - xargs rpl -w "CONFIG_$sym" "CONFIG_COMPAT_$sym" -done -</pre></code> - -<h1>Step 5</h1> - -Build a Kconfig file: - -<code><pre> -echo 'source "kernel-kconfig"' > Kconfig -for k in drivers/net/wireless/*/Kconfig ; do echo "source \"$k\"" >> Kconfig ; done -</pre></code> - -etc. Currently, mac80211/cfg80211/... Kconfig isn't copied. They will need to be copied and potentially modified for dependencies like WEXT. - -<h1>Step 6</h1> -Run menuconfig: - -<code><pre> -/lib/modules/$(uname -r)/build/scripts/kconfig/mconf Kconfig -</pre></code> - -<h1>Step 7</h1> - -Build the thing. - -The generated .config can be parsed with either the existing compat-drivers/scripts/gen-compat-autoconf.sh script or scripts/kconfig/confdata.c (conf --silentoldconfig). The generated include/linux/compat_autoconf.h is already included as part of the build of compat-drivers.
\ No newline at end of file diff --git a/wiki/Documentation.mediawiki b/wiki/Documentation.mediawiki deleted file mode 100644 index 5d52dac..0000000 --- a/wiki/Documentation.mediawiki +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Documentation ---- - -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 [http://kernel.org kernel.org]. - -= Workflows = - -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: - -* Ethernet -* Wireless -* Bluetooth -* NFC -* ieee802154 -* Media -* 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. - -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. - - -[[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].
\ No newline at end of file diff --git a/wiki/Documentation_backports_hacking.mediawiki b/wiki/Documentation_backports_hacking.mediawiki deleted file mode 100644 index f40ef4c..0000000 --- a/wiki/Documentation_backports_hacking.mediawiki +++ /dev/null @@ -1,318 +0,0 @@ ---- -title: Documentation/backports/hacking ---- - -'''NOTE: the backports project's process is being reworked and redefined. Some of the information in this page may be outdated and will be updated when the changes in the process are finalized.''' ----- - -The project has a [[Documentation/backports/hacking/todo|To-Do List]] and a [[License]]. - -= Philosophy = - -The project aims to optimize the backporting process by not only providing backported drivers but by also aiming to [http://www.do-not-panic.com/2012/08/automatically-backporting-linux-kernel.html automatically backport the Linux kernel] by [http://www.do-not-panic.com/2012/08/optimizing-backporting-collateral.html optimizing backporting collateral evolutions]. - -= Backports development flow = - -# The [https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git backports.git] "master" development branch always tracks "linux-next", allowing it to track all the development trees. -#* This ensures that, at the close of each merge window, the state of the backports will be very close to the state of the first release candidate. -# At the close of each merge window, the Backports Project creates a new branch. -#* This new branch tracks the progress of the impending release throughout the release candidate evaluation period, to the major release, and on to its lifetime as a stable kernel. - -The backports project thus makes three kinds of backports releases possible: - -* those derived from linux-next -* those derived from the most recent release candidate (if any) -* those derived from recent stable kernels. - -= Backports git tree tags and branches = - -The project uses two types of git tags: - -* daily tags following linux-next -* stable tags following either Linus' tree for rc releases or Greg's stable tree for stable extra version releases - -The project uses a master branch and a series of stable branches, a stable branch to track each stable release of the kernel. The master branch always tags linux-next, for example the backports tag backports-20141114 supports using linux-next tag next-20141114. Once Linus makes a release candidate of the kernel a respective ''stable backports branch'' is created based on the version of Linux Linus released, this backports branch will be based on a recent backports tag which was tracking linux-next. Future release candidates of the same version of Linux as well as stable release of Linux under the same version will be backported using the respective ''backports stable branch'' created. - -If any of this is fuzzy please refer to the [https://github.com/mcgrof/paper-backports/raw/master/paper.pdf Increasing Automation in the Backporting of Linux Drivers Using Coccinelle] paper, in particular the sections: - -* 1A - A. The Linux kernel development model -* 1B - A brief history of the Linux kernel backports project - -= Git trees you will need = - -The project backports a few subsystems down to older kernels. To be able to synchronize backporting the latest and greatest the [https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git linux-next.git] tree is used as its main source for kernel updates. -backports brings a general kernel compatibility part containing some backported c functions and header files in addition to patches for code in linux-next to make it work on older kernel versions and with the general kernel compatibility part. -You will need first the [https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git backports.git] tree. Once cloned you can run: - - ./devel/backports-update-manager - -That will get you all other trees and sources required for development, which are: - -* linux-next - Stephen Rothwell's tree which tracks all development trees daily -* linux - Linus' tree -* linux-stable - Greg's stable tree for stable extra version releases - -This will use git clone --reference to minimize disk usage. - -You can generate backports based on different trees depending on your needs. We are supporting build based on [https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/ linux-next.git], [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ linux.git] and [https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/ linux-stable.git]. You can also generate builds based on your own tree, but then you probably have to patch backports yourself to add support for that. - -= Tool prerequisites = - -git, python patch and coccinelle are needed to generate a backports release. The tools will complain if you do not have any of the required dependencies. - -= Generate new release = - -To generate a own backport release based on linux-next you need the following git trees: - -<code> -<pre> -git://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git -git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git -</pre> -</code> - -As linux-next changes often you should start with a working version by using a tagged version from linux-next.git and backports.git with the same date in it like backports-20130607 and next-20130607. This is a combination where someone already tested that the patches are still applying. - -After you have checked out some version of these git trees, you can start generating a tar by running ./gentree.py in the backports tree. -This will take the path to the already checked out linux-next kernel as the second last argument and the path to a directory where the newly created release should be written to as the last parameter. The releases are not created in place any more, but in a new path specified in the last parameter. - -<code> -<pre> -./gentree.py --clean --git-revision v3.x /path/to/your/linux-next /path/to/your/newly/created/release -</pre> -</code> - -= Adding new driver = - -This is a list of steps to be done when adding a new driver. Not all steps are needed for every new driver it depends on what type of driver is added. You can take the patch adding support for the ieee802154 subsystem as a reference [https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/commit/?id=a42aa4d474e5859164a00bf451970fb58b676fcf]. - -You should target the master branch of the backports repository. - -# Add directories and files that should be copied from the mainline kernel to <code>copy-list</code> -# Add patches to <code>patches/collateral-evolutions/</code> if needed, it is better to add or modify a header file in <code>backport/backport-include/</code> than adding a patch. -# Add reference to the newly added driver directory in <code>backport/Makefile.kernel</code> if needed (just needed for new substems) -# Add reference to the newly added driver directory in <code>backport/Kconfig.sources</code> if needed (just needed for new subsystems) -# Add a defconfig file for this driver in <code>backport/defconfigs/</code> and modify other defconfig files if appropriate, e.g. if you add a wifi driver add it to <code>backport/defconfigs/wifi</code> -# If the driver does not build on all kernel versions specify a minimum kernel version in <code>dependencies</code> - -Backports currently supports the latest minor version of every mainline kernel starting from 2.6.24. You should check that backports still builds after making your changes. To do so you should install all supported kernel with the script in <code>devel/get-compat-kernels</code> and then run <code>devel/ckmake</code> to build backports against every kernel version. - -= Backporting a kernel feature = - -Features being backported should either be backported into a respective backports-3.x.c file under backports/compat/ and/or their respective header file under backport/backport-include/. - -= Backports Kconfig operation = - -Go read the [https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/tree/devel/doc/kconfig-operation backports kconfig operation] documentation. - -= Backports Makefile operation = - -Go read the [https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/tree/devel/doc/makefile-operation backports Makefile operation] documentation. - -= Sending patches = - -backports contributions follow the contribution model -implemented by the Linux kernel. Patches or pull requests for backports -must have be signed-offed. If you don't sign off on them -'''they will not accepted'''. This means adding a line that says -"Signed-off-by: Name <email>" at the end of each commit, indicating -that you wrote the code and have the right to pass it on as an open -source patch. For exact definition of what the Signed-off-by tag is -you can read the definition of the "'''Developer's Certificate of Origin 1.1'''", -which you can read here: - -http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html - -Remember there are three trees. linux-next itself is a conglomeration of kernel git trees itself, so patches for linux-next.git should be sent to each respective subsystem for which the patches are targeted for. So for example for 802.11 you will want to send them to John Linville and cc linux-wireless, for further guidelines on this see the [http://wireless.kernel.org/en/developers/Documentation/SubmittingPatches Submitting Patches guidelines for 802.11]. As another example, for bluetooth you will want to send them to Gustavo Padovan and cc the linux-bluetooth mailing list. If your patch touches on others areas of the kernel refer to the MAINTAINERS file on the kernel. - -For backports.git please send patches against to: - -<code> -<pre> -To: hauke@hauke-m.de, mcgrof@kernel.org -CC: backports@vger.kernel.org -Subject: [PATCH] backports: fix foo -</pre> -</code> - -Patches are preferred sent with a clear commit log entry, if unfamiliar with how to send patches please refer to [http://wireless.kernel.org/en/developers/Documentation/git-guide a git guide]. - -= Requirements for contributions = - -The code quality, and coding style is precisely the same as followed by the Linux kernel, for that refer to [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches the Linux kernel SubmittingPatches] guide. Other than this, since we a supporting backporting you are expected to refer to the respective upstream commit which you are providing a backport for. This should describe both the git commit sha1sum on Linux, and the commit description. The description should also include the Linux kernel version which merged the commit upstream first, this can be used to help understand what target kernels the backport work was for. An example of good commit log follows: - -<pre> -commit 54584122b3279700f5ef2ba4f260a84273215947 -Author: Stefan Assmann <sassmann@kpanic.de> -Date: Fri May 16 13:21:19 2014 +0200 - - backports: handle new get_module_info and get_module_eeprom pointers in struct ethtool_ops - - In kernel 3.5 struct ethtool_ops received 2 new function pointers - get_module_info and get_module_eeprom. Address this by putting ifdef around - the code. - - commit 41c3cb6d20f0252308e9796fa4f3dacb4960de91 - Author: Stuart Hodgson <smhodgson@solarflare.com> - Date: Thu Apr 19 09:44:42 2012 +0100 - - ethtool: Extend the ethtool API to obtain plugin module eeprom data - - git describe --contains 41c3cb6d20f0252308e9796fa4f3dacb4960de91 - v3.5-rc1~109^2~124^2~2 - - Signed-off-by: Stefan Assmann <sassmann@kpanic.de> - Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> -</pre> - -= Backporting preference for EXPORT_SYMBOL_GPL() and proprietary drivers = - -This framework was designed by intent since its inception '''only''' for ''upstream'' -Linux kernel drivers to avoid excuses about the difficulty to support '''upstream''' -Linux kernel development while also supporting '''users on older kernels'''. To -ensure the intent is respected currently all symbols that we do work on to -backport are exported via '''EXPORT_SYMBOL_GPL()''' as we do work to backport them -for the supported kernels. By using EXPORT_SYMBOL_GPL() we make it '''clear''' through -the only current technical means we have that -if you use the backported symbols your software '''is considered derivative -works of the Linux kernel'''. - -= Backporting more subsystems = - -Feel free to any backport subsystems. The requirement is you at least list its kernel dependency and also that you have tested compilation success with ckmake. If you are adding a new subsystem we are in hopes you will also help maintain it. - -= Generating backports stats = - -To help backports developers evaluate the gains of use of Coccinelle SmPL a tool has been written as part of the work done towards the [http://coccinelle.lip6.fr/papers/backport_edcc15.pdf Increasing Automation in the Backporting of Linux Drivers Using Coccinelle paper], the tool has a temporary git tree on github, integration of the tool into the upstream backports tree is desirable but porting of the tool to Python must be done first. Below are instructions on how to use the tool to get stats on the latest tree. The statistics give a slew of metrics over the gains of using of Coccinelle towards automatically backporting the Linux kernel on each release. - -First git clone upstream backports git tree, and have a linux-next tree available (using Linus' tree is possible as well, you just need to use the respective stable backports branch). Then generate a backports release using --gitdebug so that each step of the backports process creates a commit. This lets the tool evaluate the impact of using Coccinelle at each step. Assuming you have backports cloned on ~/backports/ and the latest linux-next tree with the respective linux-next tag associated with the latest backports tree tag you would do: - -<code> -cd linux-next -git reset --hard next-20151218 - -cd ~/backports/ - -mkdir -p ~/build/ -rm -rf ~/build/backports-20151218 -./gentree.py --gitdebug ~/linux-next ~/build/backports-20151218 -</code> - -Now go get the temporary backports stats tool and copy over the required binary and script: - -<code> -cd ~/ -git clone https://github.com/mcgrof/backports-cocci-stats.git -cd backports-cocci-stats -make - -cp gen-cocci-stats.sh ~/build/backports-20151218/ -cp clean ~/build/backports-20151218/ -</code> - -Now generate the stats, you should see something like this: - -<code> -mcgrof@ergon ~/build/backports-20151218 (git::master)$ ./gen-cocci-stats.sh ------------------------------------------------------------------------------ -Development and Maintenance efficiency metrics: ------------------------------------------------------------------------------ - dev-efficiency maint-efficiency diff-wc diffstat clean SmPL-Patch - 0.555556 2.33333 21 5 9 0065-ndisc_send_na-argument.cocci - 2.75 8 64 22 8 0062-iff-no-queue.cocci - 0.666667 1.88889 17 6 9 skb_no_xmit_more.cocci - 1.16667 2.79167 67 28 24 ptp_getsettime64.cocci - 0.142857 1 14 2 14 features_check.cocci - 1.18182 5.45455 60 13 11 0055-netdev-tstats.cocci - 1.55906 3.55118 451 198 127 0054-struct-proto_ops-sig.cocci - 0.666667 1.88889 17 6 9 no-pfmemalloc.cocci - 0.634146 1.4878 61 26 41 set_vf_rate.cocci - 3.75 10.625 85 30 8 igb_pci_error_handlers.cocci - 1.07692 4.23077 55 14 13 ethtool_cmd_mdix.cocci - 0.588235 1.23529 21 10 17 rxnfc.cocci - 0.285714 1.53571 43 8 28 get_module.cocci - 0.285714 1.53571 43 8 28 ethtool_eee.cocci - 0.714286 2.28571 16 5 7 skb_no_fcs.cocci - 0.25 1.59375 51 8 32 set_vf_spoofchk.cocci - 0.428571 2.85714 40 6 14 sriov_configure.cocci - 0.87037 2.7037 146 47 54 0031-sk_data_ready.cocci - 4.4 17.9 179 44 10 genl-const.cocci - 7.11111 49.6667 447 64 9 0019-usb_driver_lpm.cocci - 0.571429 4.14286 58 8 14 get_ts_info.cocci - 11.5333 45.4 681 173 15 0001-netlink-portid.cocci - 2.96667 16.35 981 178 60 0002-no_dmabuf.cocci - 0.444444 1.77778 32 8 18 0002-gpio-parent.cocci - 0.512821 1.89744 74 20 39 0002-group_attr_bus.cocci - 0.769231 2.79487 109 30 39 0001-group_attr_class.cocci - 1.47184 5.6484 3711 967 657 all-SmPL.cocci ------------------------------------------------------------------------------ -Patch total diff wc -l: 3075 -SmPL total diff wc -l: 3711 -Total total diff wc -l: 6786 ---------------------------------------- -Patch diff % contribution: 45.3139 -SmPL diff % contribution: 54.6861 -</code> - -Now say you wanted to generate stats for a newer release, say for stats based on linux-next tag next-20160122, you would do: - -<code> -cd ~/linux-next/ -git reset --hard next-20160122 - -cd ~/backports/ -./gentree.py --gitdebug ~/linux-next/ ~/build/backports-20160122 - -cd ~/build/backports-20160122 -cp ~/backports-cocci-stats/gen-cocci-stats.sh . -cp ~/backports-cocci-stats/clean . -./gen-cocci-stats.sh -mcgrof@ergon ~/build/backports-20160122 (git::master)$ ./gen-cocci-stats.sh ------------------------------------------------------------------------------ -Development and Maintenance efficiency metrics: ------------------------------------------------------------------------------ - dev-efficiency maint-efficiency diff-wc diffstat clean SmPL-Patch - 0.4 2.6 13 2 5 0067-mdio-addr.cocci - 0.555556 2.33333 21 5 9 0065-ndisc_send_na-argument.cocci - 2.75 8 64 22 8 0062-iff-no-queue.cocci - 0.666667 1.88889 17 6 9 skb_no_xmit_more.cocci - 1.16667 2.79167 67 28 24 ptp_getsettime64.cocci - 0.142857 1 14 2 14 features_check.cocci - 1.18182 5.45455 60 13 11 0055-netdev-tstats.cocci - 1.55906 3.55118 451 198 127 0054-struct-proto_ops-sig.cocci - 0.666667 1.88889 17 6 9 no-pfmemalloc.cocci - 0.634146 1.4878 61 26 41 set_vf_rate.cocci - 3.75 10.625 85 30 8 igb_pci_error_handlers.cocci - 1.07692 4.23077 55 14 13 ethtool_cmd_mdix.cocci - 0.588235 1.23529 21 10 17 rxnfc.cocci - 0.285714 1.53571 43 8 28 get_module.cocci - 0.285714 1.53571 43 8 28 ethtool_eee.cocci - 0.714286 2.28571 16 5 7 skb_no_fcs.cocci - 0.25 1.59375 51 8 32 set_vf_spoofchk.cocci - 0.428571 2.85714 40 6 14 sriov_configure.cocci - 0.87037 2.7037 146 47 54 0031-sk_data_ready.cocci - 4.4 17.9 179 44 10 genl-const.cocci - 7.11111 49.6667 447 64 9 0019-usb_driver_lpm.cocci - 0.571429 4.14286 58 8 14 get_ts_info.cocci - 11.5333 45.4 681 173 15 0001-netlink-portid.cocci - 2.96667 16.35 981 178 60 0002-no_dmabuf.cocci - 0.444444 1.77778 32 8 18 0002-gpio-parent.cocci - 0.512821 1.89744 74 20 39 0002-group_attr_bus.cocci - 0.769231 2.79487 109 30 39 0001-group_attr_class.cocci - 1.46375 5.62538 3724 969 662 all-SmPL.cocci ------------------------------------------------------------------------------ -Patch total diff wc -l: 3087 -SmPL total diff wc -l: 3724 -Total total diff wc -l: 6811 ---------------------------------------- -Patch diff % contribution: 45.3237 -SmPL diff % contribution: 54.6763 -</code> - -= See also = - -* [[Documentation/backports/hacking/todo|To-Do List]] -* [[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].
\ No newline at end of file diff --git a/wiki/Documentation_backports_hacking_todo.mediawiki b/wiki/Documentation_backports_hacking_todo.mediawiki deleted file mode 100644 index 390001d..0000000 --- a/wiki/Documentation_backports_hacking_todo.mediawiki +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: Documentation/backports/hacking/todo ---- - - -The Linux kernel backports TODO list. - -= make localmodconfig support = - -The Linux kernel has ''make localmodconfig'' support, random users shouldn't be expected to know what modules they need, so in order to allow users to get only the drivers they need built we'd need something similar to ''make localmodconfig''. There are a few ways to do this. The best way would be to get upstream a mapping of a kernel object of a device to list its respective Kconfig. We'd also need a map of Kconfig changes over time as the kernel advances so that if a user is on an older system their old kobject Kconfig could be mapped to a new one. This should require changes upstream. - -Other simpler solutions are to rely on 'lspci -k' output and map this to respective device drivers but this solution would be PCI bus specific. -We should review how the upstream ''make localmodconfig'' currently works and improve upon that to enable support for it on backports. - -== Who's working on this? == - -No one. - -= Module namespaces = - -Module namespace can consist of either adding prefixes to existing symbols or modifying the Linux kernel module data structure so that upon request for a symbol it's own namespace can be inspected for its requested namespace. The Linux kernel backports project embraces prefixing backported versions of symbols by prefixing backported versions of symbols with ''backports_''. A macro LINUX_BACKPORT() was added to help with this. For example: - -<tt> - #define crc8 LINUX_BACKPORT(crc8) -</tt> - -Andi Kleen introduced the modular structure modification version of [http://thread.gmane.org/gmane.linux.network/78674 module namespaces] back in 2007 but [http://article.gmane.org/gmane.linux.kernel/606885 Rusty Russell nacked these patches]. Because of this we're left with remapping modules to their own namespaces without modifying the in-kernel module structure. It '''may''' be possible to somehow provide module namespaces without requiring modifications to the in-kernel module structure, but such mechanisms would end up being hacks. We need to evaluate if we can figure a clever way to support this that is not so error prone or if we want to respinning Andi's patches with the intent to help support kernel backporting. - -== Original motivation for module namespaces == - -Here's a brain dump from Andi about the original motivation behind module namespaces: - -The original intent was to provide a cleaner export symbol API. - -There are roughly two classes of exported symbols: - -- Generally usable, well designed, interfaces intended to be used by multiple -modules (e.g. functions for drivers to register themselves or -library functions) - -- Special purpose exports that are only really for a single -module, but are not intended as a general interface. These interfaces -are usually not really clean and reusable. - -The idea was to mark the later special purpose exports with the name of the -module that is supposed to them. They wouldn't be available -to everybody else and wouldn't become part of the general -kernel module API. - -== Motivations == - -At times Linux distributions may choose, for whatever support-nightmare reasons, to support two versions of a subsystem module and have two separate device drivers use a different version of that subsystem. The reason this is ill-advised is we stand to gain by having development done on the upstream and latest versions of each subsystem and drivers; that backports framework allows you to get that. An example helps to clarify here. Suppose a distribution wants to ship with an old version of mac80211 and have the iwlwifi driver use it, but for ath9k they'd want to ship the newer version of mac80211 and new version of ath9k. This cannot be supported unless module namespaces are created. - -Another more reasonable motivation is to avoid regressions with features / symbols being updated only for backported drivers. Non-backported drivers will use the non-backported version of the routine. This should avoid regressions with non-backported drivers using these routines. - -== Who's working on this? == - -No one. - -= DKMS support = - -Someone seems to want add support for [https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support DKMS]. Who was that? What benefits does this bring? -Isn't DKMS for proprietary modules? If so we don't want this support. We don't want proprietary drivers using the Linux kernel backports framework. - -:DKMS is for proprietary modules only because all proprietary modules are out-of-tree, and DKMS is for all out-of-tree modules, whether they are proprietary or not. Since Linux kernel backports are out-of-tree, DKMS brings the benefit of automagically keeping existing backports active when a new kernel is installed, rather than going back to the in-tree modules with every new kernel. [[User:Daniel Gimpelevich|danielg4]] ([[User talk:Daniel Gimpelevich|talk]]) 21:24, 3 April 2022 (UTC) - -== Who's working on this ? == - -No one - -[[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].
\ No newline at end of file diff --git a/wiki/Documentation_compat-drivers.mediawiki b/wiki/Documentation_compat-drivers.mediawiki deleted file mode 100644 index 6a72039..0000000 --- a/wiki/Documentation_compat-drivers.mediawiki +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: Documentation/compat-drivers ---- - -compat-drivers is the framework that '''pulls''' code from Linux kernel releases and strives to backport them ''automatically'' for usage on older Linux kernel releases. compat-drivers allows us to make releases of code from newer Linux kernel releases and get the latest drivers to users without having to recompile their entire kernel. - -<h1>Supported Linux kernel releases</h1> - -The [http://kernel.org/ kernel.org] archive hosts '''all''' kernel releases. As the Linux kernel development moves on older kernels get '''deprecated''' and a few kernels remain supported. It is imperative that end users / system integrators / Linux distributions upgrade to newer '''supported''' kernels regularly otherwise they may end up being stuck on '''unsupported''' kernels. The compat-drivers project aims at '''always''' providing support of newer drivers down to ''at least'' '''all supported Linux kernel releases''' as listed on [http://kernel.org/ kernel.org]. As it is though the project currently takes backporting further and it does support a large amount of older unsupported and deprecated Linux kernel releases. As it is right now all 21 older kernels are supported: 2.6.24 - 3.6. - -<h1>Release types</h1> - -There are two release types, linux-stable and linux-next releases, for details refer to the [[Releases|releases page]]. There are also modifications to releases and an extra set of flags are appended to releases depending on the series of types of patches applied to them. For details on these different type of patches that can be applied onto a release refer to the [[Documentation/compat-drivers/additional-patches#Legend_of_additional_patches|legend of additional patches]] section. - -<h1>Backported subsystems</h1> - -There are three subsystems currently backported through this framework. - - * Ethernet - * Wireless - * Bluetooth - -The video drivers are currently on their way to being integrated. - -<h2>Subsystem requirements</h2> - -In order to compile and install modules from the compat-drivers releases you will need to have your kernel headers installed on your system. As you get new drivers though you may need to install newer firmware as well so be sure to always have in synch your '''/lib/firmware/''' directly with the latest firmware from the [http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=summary linux-firmware.git tree]. - -Each backported subsystem may also take advantage of newer userspace APIs and as such you should upgrade each subsystem's recommended userspace as documented here. - -<h3>Userspace upgrade for wireless</h3> - -We recommend these the following 802.11 wireless userspace applications should be upgraded: - - * [http://wireless.kernel.org/en/developers/Regulatory#The_regulatory_database wireless-regdb] - * [http://wireless.kernel.org/en/developers/Regulatory/CRDA CRDA] - * [http://wireless.kernel.org/en/users/Documentation/iw iw] - * [http://wireless.kernel.org/en/users/Documentation/rfkill rfkill] - * [http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=summary linux-firmware] - * [http://wireless.kernel.org/en/users/Documentation/wpa_supplicant wpa_supplicant] - * [http://wireless.kernel.org/en/users/Documentation/hostapd hostapd] - -<h3>Userspace upgrade for bluetooth</h3> - -Someone should edit this and update this. - -<h3>Userspace upgrade for ethernet</h3> - -Someone should edit this and update this. - -<h1>Building and installing</h1> - -This section covers how to use build and install compat-drivers. - -<h2>Selecting your driver</h2> - -compat-drivers allows you to selectively build only one driver instead of building all backported drivers. - -<h2>Extracting compat-drivers</h2> - -Extract the content of the package: - -<pre> -tar jxvf compat-drivers-$(date -I).tar.bz2 -</pre> - -If you know what driver you want you can use driver-select: - -<pre> -./scripts/driver-select -</pre> - -Selecting your driver can reduce the amount of time to compile compat-drivers. It may also enable kernel compatibility down to older kernels. If you want to restore compat-drivers to enable all drivers again you can use: - -<pre> -./scripts/driver-select restore -</pre> - -If you do not see your driver in the supported list it means care has not been taken to ensure it works with driver-select and you must just build compat-drivers as a whole. - -<h2>Building and installing</h2> - -This section documents how to build and install compat-drivers. - -<h2>Building compat-drivers</h2> - -Build the latest backported Linux subsystems: - -<pre> -cd compat-wireless-$(date -I) -make -</pre> - -<h2>Installing compat-drivers</h2> - -We use the updates/ directory so your distribution's drivers are left intact. By default depmod will search for this directory first, but if you find that it does not then check that your depmod.conf file lists the search order correctly with ''updates'' appearing first (before ''built-in''). the package should automatically detect this for you and deploy an update for you. - -<pre> -sudo make install -</pre> - -<h2>Uninstalling compat-drivers</h2> - -This nukes our changes to updates/ so you can go back to using your distribution's supported drivers. - -<pre> -sudo make uninstall -</pre> - -<h1>Unloading your old distribution drivers</h1> - -Since you might be replacing your old subsystem drivers you should first try to unload all existing related drivers. We provide a mechanism to unload all drivers: - -<pre> -sudo make unload -</pre> - -If unsure just reboot. - -<h2>Loading compat-drivers</h2> - -Before loading modules you must first unload your old subsystem modules. Read above how to do this. If you know what module you need you can simply load the module using modprobe. If you are not sure you can just reboot the box. - -<h2>Building for external kernels</h2> - -If you have a kernel you do not have installed but yet want to build the compat-drivers for it you can use this syntax: - -<pre> -make KLIB=/home/mcgrof/kernels/linux-2.6.27.22 \ - KLIB_BUILD=/home/mcgrof/kernels/linux-2.6.27.22 -</pre> - -<h1>Additional patches</h1> - -Read the [[Documentation/compat-drivers/additional-patches|additional patches]] section for details of how '''emergency''' or '''critical''' fixes are dealt with while still '''prioritizing''' Linux upstream development. - -<h1>Bugs</h1> - -Please see the [[Documentation/reporting-bugs|reporting bugs section]]. This cannot be stressed enough: '''to date we have only have identified 2 backport related bugs''', all other reported bugs''' were real bugs in actual upstream code''' so be sure to report any bugs found '''ASAP'''! - -<h1>License</h1> -This work is a subset of the Linux kernel as such we keep the kernel's Copyright practice. Some files have their own copyright and in those cases the license is mentioned in the file. All additional work made to building this package is licensed under the GPLv2. - -<h1>Hacking compat-wireless</h1> -If you'd like to hack on compat-drivers or make your own releases refer to the [[Documentation/compat-drivers/hacking|hacking compat-drivers page]]. - -<h1>Administrative</h1> -The way compat-drivers releases are made, where they are kept are detailed in the [[Documentation/compat-drivers/admin|compat-drivers admin page]].
\ No newline at end of file diff --git a/wiki/Documentation_compat-drivers_additional-patches.mediawiki b/wiki/Documentation_compat-drivers_additional-patches.mediawiki deleted file mode 100644 index 749f3b2..0000000 --- a/wiki/Documentation_compat-drivers_additional-patches.mediawiki +++ /dev/null @@ -1,192 +0,0 @@ ---- -title: Documentation/compat-drivers/additional-patches ---- - -This is now deprecated use [[Documentation/backports/hacking|hacking on backports]]. - -<h1>Additional patches to stable releases</h1> - -compat-drivers '''prioritizes''' pushing software to be '''upstreamed''' into ''respective'' Linux subsystem development trees. The stable compat-drivers releases are based on vanilla stable kernels and extra version stable (3.x.y) releases as published through the [http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary linux-stable.git] tree. Stable fixes are propagated through the [http://wireless.kernel.org/en/users/Documentation/Fix_Propagation stable kernel fix propagation mechanism]. At times however the [http://wireless.kernel.org/en/users/Documentation/Fix_Propagation stable kernel fix propagation mechanism] may not allow OEMs/OSVs/users to get the latest stable patches in time for their own needs. Other times, some patches which are not necessarily ''"stable"'' fixes may be desired to be integrated into a stable release by a hardware manufacturer, for one reason or another. At times, a subsystem maintainer may be on vacation and stable fix patches may take a while to get to users. In the worst case scenario some patches may not have been submitted for public review yet, for whatever reason, but it may be desired to merge some temporary patches on a stable release. Because of all these reasons compat-drivers has extended the [http://wireless.kernel.org/en/users/Documentation/Fix_Propagation stable kernel fix propagation mechanism] by enabling additional types of patches to be merged into a stable release. '''Upstream first''' is still prioritized by categorizing these patches. - -There are five categories to compat-wireless' extra patches: - - * pending-stable - * linux-next-cherry-picks - * linux-next-pending - * crap - * unified-drivers - -We document these below. - -<h2>Legend of additional patches</h2> - -Releases can either be vanilla releases or have a series of additional patches applied to the release on top of the vanilla release. A flag is appeneded at the end of a release to annotate patches from a specific directory have been applied to this release. The appended extra flag meanings follows: - - * -s - get and apply pending-stable/ from linux-next.git - * -n - apply the patches linux-next-cherry-picks/ directory - * -p - apply the patches on the linux-next-pending/ directory - * -c - apply the patches on the crap/ directory - * -u - apply the patches on the unified-drivers/ directory - -Release with no extra flags are simply vanilla releases of the kernel. Users / Linux distributions are encouraged to use the ''-uspn'' releases if they are available, otherwise the ''-spn'' relases as these releases will have extra fixes not yet propagated. The ''-s'' flag for example indicates that the release has patches marked as stable which will be released by the next 3.x.y release of the kernel so you might as well get them now. Linux distributions are encouraged to use the extra flagged releases as well. We provide the vanilla releases for those Linux distributions which just want vanilla for whatever reason. - -Each category is documented below. - -<h2>Annotating cherry pick preference</h2> - -If you want to annotate that a patch should be considered for inclusion into -the stable releases of compat-drivers under linux-next-cherry-picks/ you -can annotate it by adding a tag on the commit log line, ''Cc: backports@vger.kernel.org''. -An example follows. By annotating these patch a script can be used to scrape -linux-next for extracting these patches when building a stable release. - -<code><pre> -commit 061acaae76dfb760f4f3fddf0cde43915b7d673c -Author: Luis R. Rodriguez <rodrigue@qca.qualcomm.com> -Date: Wed Dec 7 21:50:07 2011 +0530 - - cfg80211: allow following country IE power for custom regdom cards - - By definition WIPHY_FLAG_STRICT_REGULATORY was intended to allow the - wiphy to adjust itself to the country IE power information if the - card had no regulatory data but we had no way to tell cfg80211 that if - the card also had its own custom regulatory domain (these are typically - custom world regulatory domains) that we want to follow the country IE's - noted values for power for each channel. We add support for this and - document it. - - This is not a critical fix but a performance optimization for cards - with custom regulatory domains that associate to an AP with sends - out country IEs with a higher EIRP than the one on the custom - regulatory domain. In practice the only driver affected right now - are the Atheros drivers as they are the only drivers using both - WIPHY_FLAG_STRICT_REGULATORY and WIPHY_FLAG_CUSTOM_REGULATORY -- - used on cards that have an Atheros world regulatory domain. Cards - that have been programmed to follow a country specifically will not - follow the country IE power. So although not a stable fix distributions - should consider cherry picking this. - - Cc: backports@vger.kernel.org - Cc: Paul Stewart <pstew@google.com> - Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> - Cc: Senthilkumar Balasubramanian <senthilb@qca.qualcomm.com> - Reported-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> - Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> - Signed-off-by: John W. Linville <linville@tuxdriver.com> -</pre></code> - -<h2>pending-stable patches</h2> - -These are patches merged into linux-next.git but that have not yet been merged into the linux-stable.git tree. - -From the pending-stable/README: - -<code><pre> -Often right before the merge window we get a block on non -oops/regression fixes for stable fixes. Some stable fixes -often get propagated afterwards during the extraversion -maintenance of the kernels. Right before the merge window -circa rc4 and rc5 subsystem maintainers get pegged if they -throw in non oops/regression fixes for Linus or their -respective upstream maintainer. While this makes sense -for tree management and stable release considerations we -still need to get users some stable patches propagated. - -This directory is there to help with that. Only patches -which have been merged into linux-next.git will be included -in this directory which means you must post it and the maintainer -should have merged it and Stephen would have picked it up. - -This directory will always be empty for bleeding edge -releases as bleeding edge releases are always based on -linux-next already. This directory only makes sense for -stable release of the kernel, and it we will always try -to use it, in case there are stable fixes not yet propagated. -</pre></code> - -<h2>linux-next-cherry-picks patches</h2> - -From the linux-next-cherry-picks/README: - -<code><pre> -We work hard to get patches in time onto the stable -tree but sometimes a few things slip out, and sometimes a -stable fix is simply too big in size to be merged into -stable. In such cases though we do believe some of these -patches are still relatively important to either enable new -hardware which escaped the late rc cycles or to correct some -behaviour which might be too late for stable. We apply -these patches by default as they will be supported on these -releases. - -The larger the number of patches you see in this directory -the more we should be ashamed. We should strive to reduce this -to 0 all the time. - -This directory will always be empty for bleeding edge -releases as bleeding edge releases are always based on -linux-next already. -</pre></code> - -<h2>linux-next-pending patches</h2> - -From the linux-next-pending/README: - -<code><pre> -You must have a really good reason to be adding files -in this directory. The requirement is your patches must have -been posted to a public mailing list for the subsystem you are -working on. Each patch you add here must have a really good -explanation on the top of the file which clarifies why the -patch has not yet been merged OR specify it on the commit log -when you add it on compat-wireless. - -We try to avoid having patch files because but we understand -if you might because you need to test code posted but not yet -merged into linux-next or a stable kernel release. This can happen -often during the merge window, when the maintainers are unavailable, -on vacation, suck at what they do, or for any other uncontrollable -reasons. -</pre></code> - -<h2>crap patches</h2> - -From the crap/README: - -<code><pre> -If you are including patches into this directory you -must be fixing some critical bug for a customer which needs -immediate release or immediate testing. - -Alternatively you would use this to apply some sort of -crap code you are maintaining. - -You must have a really good reason to be adding files -in this directory. If possible you should explain your -reasoning of why the patch is getting included here and -not upstream and why it hasn't even yet been posted. - -You should avoid these patches at all costs. -</pre></code> - -<h2>unified-drivers patches</h2> - -From the unified-drivers/README.md: - -<code><pre> -compat-drivers supports developers to supply a unified -driver git tree which is being used to target support -for getting the driver in line with requirements for -linux-next. Once the driver gets upstream the driver -gets removed and we cherry pick updated version of the -driver directly from linux upstream. - -The code provided on this tree must try to adhere to -conventions for targetting inclusion into linux-next. -The compat-drivers patches/unified-drivers/ directory -allows for any additional required backport delta to -be addressed for the supplied driver. This allows -development and transformation of the driver to always -be targetting linux-next and allows for backporting -to be dealt with separately. -</code></pre>
\ No newline at end of file diff --git a/wiki/Documentation_compat-drivers_hacking.mediawiki b/wiki/Documentation_compat-drivers_hacking.mediawiki deleted file mode 100644 index c855097..0000000 --- a/wiki/Documentation_compat-drivers_hacking.mediawiki +++ /dev/null @@ -1,208 +0,0 @@ ---- -title: Documentation/compat-drivers/hacking ---- - -This is now deprecated use [[Documentation/backports/hacking|hacking on backports]]. - -This section deals with development details of compat / compat-drivers and the other trees it uses. If you want to make your own compat-drivers tarballs, or if you see something busted with compat-drivers or just want to add something new or an enhancement this is the guide for you. - -<h1>Git trees you will need</h1> - -compat-drivers backports a few subsystems down to older kernels. To be able to synchronize backporting the latest and greatest the [http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary linux-next.git]] tree is used as its main source for kernel updates. General Linux kernel compatibility is addressed through a general kernel compatibility tree, [https://github.com/mcgrof/compat compat.git]. compat-drivers then has its own tree for specific subystem target backports. You will then need to checkout a few trees to start hacking on compat-drivers, you can use the [[Code#Getting_all_required_code|instructions on getting all required code]] to get all trees but below we provide the list of the git trees used. - - * git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git - * git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git - * git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git - - * git://github.com/mcgrof/compat.git - * git://github.com/mcgrof/compat-drivers.git - -<h1>Linux next</h1> - -The [http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary linux-next.git] tree brings all subsystems being worked on for the '''next kernel release''' into one tree. So if the current rc kernel is v3.6-rc1, this means linux-next will have what people today are working on for the 3.7 kernel release. - -<h1>backports components</h1> - -Go read the [[Documentation|backports documentation]] for a list of backport components and ensure you understand what each one is supposed to do. Below is a quick description though for the big picture. - -<h2>compat.git</h2> - -The compat git tree is a general kernel compatibility layer which can be shared amongst different compatibility projects, or drivers. compat-drivers is just one of the kernel compatibility projects using compat.git. compat.git builds a general compatibility module, compat, and any additional modules to let you get new general kernel updates from future kernels on your old kernels. - -<h2>compat-drivers.git</h2> - -Anything that is not general kernel compatibility but instead specific to a subsystem goes into compat-drivers.git. After you've cloned all three trees, linux-next.git, compat.git and compat-wireless.git you need to change into the compat-drivers directory and tell compat-drivers where you linux-next and compat.git trees are. You do this with environment variables GIT_TREE and GIT_COMPAT_TREE. You can do for example: - -<code> -<pre> -export GIT_TREE=/home/user/linux-next/ -export GIT_COMPAT_TREE=/home/users/compat/ -</pre> -</code> - -Then you can then update your local sources based on these linux-next.git and compat.git trees: - -<code> -<pre> -scripts/admin-clean.sh - Cleans the compat-drivers tree -scripts/admin-update.sh - Updates compat-drivers with your git tree -scripts/admin-refresh.sh - Does the above two -</pre> -</code> - -<h1>Adding new drivers</h1> - -Most new drivers are enabled for compilation. If see a driver you would like enabled try adding it into the mix, test them and if they work enable them and send the respective patches. - -<h1>Generating stable releases</h1> - -You can make stable releases yourself by checking out the specific branch for the target stable kernel release you want on each git tree: - - * [http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary linux-stable.git] - * [https://github.com/mcgrof/compat-drivers compat-drivers.git] - * [https://github.com/mcgrof/compat compat.git] - -You will also want an updated [http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary linux-next.git], you want to ensure that the tag for the target kernel you want is present if you want to cherry pick out stable patches from it. So for example if v3.5.1 was released you want to ensure the [http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary linux-next.git] tree you have is updated with the v3.5.1 tag. The [http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary linux-next.git] tree however is '''not''' carry the extra version stable releases however though so to add these tags you can add the both the linux.git and linux-stable.git as remotes to your '''linux-next/.git/config''' file: - -<pre> -[remote "next"] - fetch = +refs/heads/*:refs/remotes/origin/* - url = /home/mcgrof/linux/.git -[remote "stable"] - fetch = +refs/heads/*:refs/remotes/origin/* - url = /home/mcgrof/linux-stable/.git -</pre> - -Then do on your linux-next directory: - -<code> -<pre> -git fetch next -git fetch -t next -git fetch stable -git fetch -t stable -</pre> -</code> - -Now, for example if you wanted to make a v3.5.y stable release, you would do: - -<code> -<pre> -# On linux-next.git: -mcgrof@tux ~/linux-next (git::master)$ git fetch -remote: Counting objects: 43056, done. -... etc ... -mcgrof@tux ~/linux-next (git::master)$ git reset --hard origin -HEAD is now at 74bdbee Add linux-next specific files for 20110329 -# Now get kernel extraversions on linux-next.git, this allows you -# to extract stable patches from linux-next.git when the linux-2.6-allstable -# tree moves to a new extraversion release. -mcgrof@tux ~/linux-next (git::master)$ git fetch stable -mcgrof@tux ~/linux-next (git::master)$ git fetch -t stable - -# For compat-drivers.git: -mcgrof@tux ~/devel/compat-drivers (git::master)$ git checkout -b linux-3.5.y origin/linux-3.5.y -Branch linux-3.5.y set up to track remote branch linux-3.5.y from origin. -Switched to a new branch 'linux-3.5.y' -mcgrof@tux ~/devel/compat-drivers (git::linux-3.5.y)$ - -# For compat.git: -mcgrof@tux ~/compat (git::master)$ git checkout -b linux-3.5.y origin/linux-3.5.y -Branch linux-3.5.y set up to track remote branch linux-3.5.y from origin. -Switched to a new branch 'linux-3.5.y' -mcgrof@tux ~/compat (git::linux-3.5.y)$ - -# For linux-stable.git: -mcgrof@tux ~/linux-stable (git::master)$ git checkout -b linux-3.5.y origin/linux-3.5.y -Branch linux-3.5.y set up to track remote branch linux-3.5.y from origin. -Switched to a new branch 'linux-3.5.y' -</pre> -</code> - -Once you have the appropriate branches checked out, you can use a script designed to let you make a release: - -<pre -<code> -# First tell compat-wireless scripts your target GIT_TREE -# from where you want to suck out code from is the stable tree: -mcgrof@tux ~/devel/compat-drivers (git::linux-3.5.y)$ export GIT_TREE=/home/mcgrof/linux-stable/ - -# Then generate a stable release: -mcgrof@tux ~/devel/compat-drivers (git::linux-3.5.y)$ ./scripts/gen-stable-release.sh -s -n -Skipping linux-stable git tree update checks for branch: linux-3.5.y -On linux-stable: linux-2.3.5.y -You said to use git tree at: /home/mcgrof/linux-stable for linux-next -Copying /home/mcgrof/linux-stable/include/linux/ieee80211.h -Copying /home/mcgrof/linux-stable/include/linux/ieee80211.h -Copying /home/mcgrof/linux-stable/include/linux/nl80211.h -Copying /home/mcgrof/linux-stable/include/linux/pci_ids.h -... -Creating compat-wireless-3.5.1-1-sn.tar.bz2 ... - -Compat-wireles release: compat-wireless-v3.5.1-1-sn -Size: 4.3M compat-wireless-v3.5.1-1-sn.tar.bz2 -sha1sum: b0ca93dbda466b22ed76a8e4792c89931090d7b3 compat-wireless-v3.5.1-1-sn.tar.bz2 - -Release: /tmp/staging/compat-wireless/compat-wireless-v3.5.1-1-sn.tar.bz2 -</pre> -</code> - -Note that if you supplied the -s flag you will want to review the output for the place where it generates the pending-stable patches. If the respective target upstream tag was not found on linux-next.git it will tell you. - -If you want to add additional non-upstream patches you can use the crap/ directory and use the -c flag as well. When people review your tarball they can then find your delta easily. If you submit patches upstream you can stuff them into linux-next-pending/ and use -p. If your patch is upstream on linux-next.git you can cherry pick it out and stuff it into linux-next-cherry-picks/ and use -n. The purpose of all this effort is to enable customizations but to also allow reviewers to quickly find deltas and ensure code gets upstream properly. Check each respective directory README for a review of the directories intent and content. - -<h1>Sending patches</h1> - -compat and compat-drivers contributions follow the contribution model -implemented by the Linux kernel. Patches or pull requests for compat and -compat-drivers must have be signed-offed. If you don't sign off on them -'''they will not accepted'''. This means adding a line that says -"Signed-off-by: Name <email>" at the end of each commit, indicating -that you wrote the code and have the right to pass it on as an open -source patch. For exact definition of what the Signed-off-by tag is -you can read the definition of the "'''Developer's Certificate of Origin 1.1'''", -which you can read here: - -http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html - -Remember there are three trees. linux-next itself is a conglomeration of kernel git trees itself, so patches for linux-next.git should be sent to each respective subsystem for which the patches are targeted for. So for example for 802.11 you will want to send them to John Linville and cc linux-wireless, for further guidelines on this see the [http://wireless.kernel.org/en/developers/Documentation/SubmittingPatches Submitting Patches guidelines for 802.11]. As another example, for bluetooth you will want to send them to Gustavo Padovan and cc the linux-bluetooth mailing list. If your patch touches on others areas of the kernel refer to the MAINTAINERS file on the kernel. - -For compat.git and compat-drivers.git please send patches against to: - -<code> -<pre> -To: Luis R. Rodriguez <mcgrof@kernel.org> -CC: backports@vger.kernel.org -Subject: [PATCH] compat-2.6: fix foo -</pre> -</code> - -For patches for compat.git please use a subject like the following: - -<code> -<pre> -Subject: [PATCH] compat: fix foo -</pre> -</code> - -For compat-drivers.git please use a subject like the following: - - -<code> -<pre> -Subject: [PATCH] compat-drivers: fix foo -</pre> -</code> - -Patches are preferred sent with a clear commit log entry, if unfamiliar with how to send patches please refer to [http://wireless.kernel.org/en/developers/Documentation/git-guide a git guide]. - -<h1>TODO</h1> - - * Dialog (make menuconfig) option for this package -- [[config-brainstorming]] - * Add support for [https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support DKMS] - * Add more subsystems - * media (e.g. DVB-T devices) - -<h1>Administrative</h1> - -The way compat-drivers releases are made, where they are kept are detailed in the [[admin|compat-drivers admin page]].
\ No newline at end of file diff --git a/wiki/Documentation_compat.mediawiki b/wiki/Documentation_compat.mediawiki deleted file mode 100644 index 0546d49..0000000 --- a/wiki/Documentation_compat.mediawiki +++ /dev/null @@ -1,141 +0,0 @@ ---- -title: Documentation/compat ---- - -This is now deprecated use [[Documentation/backports/hacking|hacking on backports]]. - -This page is dedicated to compat, a generic Linux kernel backport compatibility module that has been brewing since 2009. The compat module provides functionality introduced in newer kernels to older kernels through a set of header files and exported symbols. The compat module allows code from newer kernel releases to be used on older kernels without modifications with a few exceptions. Exceptions to achieve automatically backporting kernel code through the compat module are dealt with through specific mechanisms documented in the [[compat-drivers|compat-drivers project page]] and most recently through the [http://www.linuxplumbersconf.com/2011/ocw/system/presentations/771/original/kernel-backport-for-good.odp slides used at the 2011 Linux Plumbers presentation on automatically backporting the kernel] and its [https://docs.google.com/presentation/d/1axVNEGwKZjnzG1ocdd289WMqPxzJ3qfMv70ghGcnUKc/edit follow up presentation] at the 2012 Linux Collaboration summit in San Francisco. - -By using compat and frameworks such as [[compat-drivers|compat-drivers]], and techniques to integrate [http://wireless.kernel.org/en/users/Download/stable/#Additional_patches_to_stable_releases additional patches] into upstream releases that prefer and push for upstream, we hope to ensure developers can <b>prioritize</b> working directly <b>upstream</b> on the Linux kernel and provide deliverables to end users and customers for <b>any</b> target kernel. - -compat-drivers today automatically backports the [http://wireless.kernel.org/ Wireless], [http://www.bluez.org/ Bluetooth] and [https://www.linuxfoundation.org/collaborate/workgroups/networking/ethernet Ethernet] drivers directly from the Linux kernel on a daily basis by using [http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary linux-next.git]. We also make [http://wireless.kernel.org/en/users/Download/stable/ stable backport releases] by using the [http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary linux-stable.git] tree. We are considering expanding this framework to automatically backport more drivers -- patches are welcomed, otherwise, you'll have to wait until someone decides to integrate other subsystems. - -<h1>Supported kernels</h1> - -The goal is to backport new kernel functionality <b>at least</b> down to the oldest stable supported kernel listed on [http://kernel.org kernel.org], but backporting code further is certainly welcomed. Currently this means supporting backporting down to the <i>2.6.27</i> Linux kernel release. Although our goal is to <b>at least</b> support backport efforts down to <i>2.6.27</i> the compat module currently has code to support even older kernels, and we welcome code to support older kernels as well. - -<h1>Mailing list</h1> - -See the [[mailing_list|Backports mailing list]] page. - -<h1>Presentations</h1> - -Metrics explaining the amount of code saved by automatically backporting the kernel using compat and current research are explained. - - * [http://linuxplumbersconf.org/2011/ocw/proposals/771 2011 Linux plumbers kernel backport presentation] ([http://www.linuxplumbersconf.com/2011/ocw//system/presentations/771/original/kernel-backport-for-good.odp slides]) - * [https://docs.google.com/presentation/d/1axVNEGwKZjnzG1ocdd289WMqPxzJ3qfMv70ghGcnUKc/edit follow up presentation Automatically backporting the Linux kernel - 2012 Linux Collaboration summit] - -<h1>Estimating deliverables</h1> - -Once you use compat and kernel framework integrators such as [[compat-drivers|compat-drivers]] you should have no excuse to work outside of the <b>upstream</b> Linux kernel. In order to help <i>guestimate</i> when your <i>upstream</i> code will be available through a stable release such as the [[releases|compat-drivers stable releases]] you can rely on the [http://phb-crystal-ball.org/ phb-crystall-ball]. - -<h1>Tracking down when a feature went upstream</h1> - -The compat module expect you to put functionality into either header files for defines and static inlines or into c files. This functionality must be tucked away under a file for the kernel release that <b>introduced</b> the functionality. To help aid you with your scavenger hunt on tracing down when a specific functionality was introduced into the upstream Linux kernel you can use several techniques. This section documents those techniques. - -<h2>Git tree setup for backporting</h2> - -In order to understand how to track a feature in the Linux kernel you must first understand how the development of the Linux kernel happens. Below we provide a basic description of how this works. - -Greg Kroah-Hartman maintained the stable series of the Linux kernel. Linus hands off kernel maintainership to Greg after he blesses the first release of a stable kernel. Greg maintains the stable kernel via through the [http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary linux-stable.git] tree. Each stable release of the kernel has a respective <i>origin/linux-3.x.y</i> branch, where x is the current release number. The <i>"y"</i> here is literal, so for the <i>3.2</i> release there is an <i>origin/linux-3.2.y</i> branch that keeps track of the <i>3.2.1</i>, <i>3.2.2</i> and future extra version releases of the <i>3.2</i> release. You can use the [http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary linux-stable.git] tree to verify if code is present on a stable release of a kernel. - -Linus maintains the release candidates of the Linux kernel (RC) up to the point he blesses away the first release of a kernel release. So for example Linus maintained the 3.2 kernel from the inception of <i>3.2-r1</i> down to <i>3.2-rc7</i>. During the <i>3.2-rc1</i> to <i>3.2-rc7</i> release Linus is <i>supposed</i> to only accept <b>regression fixes</b>. After that he releases the first blessed release of <i>3.2</i> and handed off maintainership to Greg. All the magic that went into <i>3.2-rc1</i> though happens in what we call the <b>development cycle</b> of the Linux kernel. The development cycle of the Linux kernel varies subsystem to subsystem but the idea can be best described in terms of the usage of two subsystem git trees. Subsystem maintainers typically have to maintain two git trees, a <i>subsystem.git</i> tree and a <i>subsystem-next.git</i> tree. The <i>subsystem.git</i> tree contains code that should go into Linus' tree during the <i>regression</i> testing of the <i>RC</i> release of the kernel. The <i>subsystem-next.git</i> contains code is being queued up for the next release of the Linux kernel, hence the "<i>-next</i>" postfix. All code in the <i>subsystem-next.git</i> trees is <i>ephemeral</i>, that is, what you see there today does not mean that it will be present tomorrow, it is code that is simply accepted on that day by the subsystem maintainer, but a lot of it can simply be dropped, and in fact Linus can reject merging it eventually. Linus will start merging all <i>subsystem-next.git</i> trees into his own tree during what we call, the <b>merge window</b>. This typically consists of a 2-3 week window period. For example the merge window for the 3.2 kernel started after Linus released the <i>v3.1</i> kernel release on Mon Oct 24, 2011, and ended when Linus released the <i>v3.2-rc1</i> release on Mon Nov 7, 2011, the <i>merge window</i> in this case lasted exactly 2 weeks. - -The <b>merge window</b> can often be painful though and to aid with this Stephen Rothwell has decided to take up merging all <i>subsystem-next.git</i> trees into one tree, [http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary linux-next.git] on a <i>daily basis</i>. He rants to each subsystem maintainer on any issues during his merge, including build breakage and general insanity. - -The implications here are that we can not only track code that is already released, but we can also predict what <i>likely</i> will go into the next release of the Linux kernel by using [http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary linux-next.git]. This means we can backport the Linux kernel <i>proactively</i> through every subsystem development cycle by using [http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary linux-next.git]. - -If this is still a bit fuzzy you can review the [http://wireless.kernel.org/en/developers/process wireless development process] for a review of how that specific subsystem development works. The development process there even includes a shiny diagram. - -<h2>Using git grep to identify what file adds new functionality</h2> - -First you want to identify what file added the functionality you seek to backport. Suppose you want to identify what file adds a new function, <i>foobar()</i>. To do this you can use: - -<pre>git grep foobar\(</pre> - -to identify where <i>foobar()</i> is used in the entire Linux kernel. <i>git grep</i> will use the indexed data and at times can often run faster than a regular grep, as it will also skip object file in a regular grep search. Given that the point of compat is to backport functionality and that this functionality is typically shared between modules and subsystems, you can rest assured most functionality has a declaration in the header files of the Linux kernel. You can typically save yourself <i>git grep</i> time by starting to search through the <i>include/</i> directory of the Linux kernel. - -<pre>git grep foobar\( include/</pre> - -<h2>Using git blame to identify introduction of a commit</h2> - -Typically compat will have a lot of features already backported for older kernels, so to help backport new functionality you should be using [http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary linux-next.git]. To identify at what point a specific feature was added into the Linux kernel you can use <i>git blame</i> to identify the sha1sum of the commit that added the functionality you want to backport. At times though such functionality may have not been introduced via that commit but instead it may have simply been moved from one place to another. You can use - -<pre>git blame sha1sum~1</pre> - -to review if the functionality was present <i>before</i> the last commit you identified added that functionality to a file. - -<h2>Using git describe to identify where an commit was introduced</h2> - -Once you have identified the commit that introduced a specific functionality you can use <i>git describe --contains sha1sum</i> to give you the first commit <i>tag</i> that contains the commit. You can use the base of the <i>tag</i> to help you figure out the first kernel release that added the commit. - -For example, commit <i>600715dcdf567c86f8b2c6173fcfb4b873e25a19</i>, or short, <i>600715dc</i> added to the Linux kernel the CONFIG_PHYS_ADDR_T_64BIT feature. We can determine that it was added on the v2.6.28 release by reviewing the results of using - -<pre>git describe --contains 600715dc</pre> - -which yields: <i>v2.6.28-rc1~271^2^4~6</i>. This means that in order to backport <i>600715dc</i> we can edit two files on compat: - -<ul> - <li>include/linux/compat-2.6.28.h</li> - <li>compat/compat-2.6.28.c</li> -</ul> - -Since this functionality can be dealt with header files the c file is not touched to backport this functionality. You can review the respective [https://github.com/mcgrof/compat/commit/4ec0edbd1cc2e6165e29f8ba466324e975e1cd73#include compat CONFIG_PHYS_ADDR_T_64BIT backport via gitweb]. - -<h1>Testing across kernels</h1> - -The goal behind compat is to add features to provide backport but to older kernels but to do this successfully we must also ensure that each new patch added does not break building against a supported kernel. It may be a daunting task to get all supported kernels to and also to build against then, which is why we have started adding support to do all of this for you. Under the bin/ directory you will find two scripts which we document below: - -<ul> - <li>get-compat-kernels</li> - <li>ckmake</li> -</ul> - -<h2>get-compat-kernels</h2> - -You can run this script to install all known supported kernels. Currently this will only work for Ubuntu, but [https://lkml.org/lkml/2012/2/6/85 work is being considered] to standardize on the same kernels for any Linux distribution. - -<h2>ckmake</h2> - -You can run this to test compiling compat against supported kernels available. Although initially designed to support Ubuntu only the goal is to make this Linux distribution agnostic. - -<h1>compat modules</h1> - -compat.git provides a few modules and headers to help with general kernel compatibility. - -<h2>compat module</h2> - -Provides all exported symbols implemented in each respective kernel compat-2.6.xy.c files. Upon module load it just initializes the Linux kernel's ''power management Quality Of Service'' (aka '''pm-qos''') Interface interface added as of the 2.6.24 kernel. No other things are initialized, the rest of the compat module just acts as a library of exported symbols. - -<h2>compat_firmware_class module</h2> - -Another module which compat.git provides is a backport of the firmware_class module which got updated recently newer with a new request_firmware_nowait() to allow better asynchronous firmware uploading. This was added as of the 2.6.33 kernel. The firmware_class module has been backported into a new module called compat_firmware_class. A separate module has been defined instead of a direct replacement for firmware_class since your system may have old drivers which use the old request_firmware_nowait() and would bust if they used the new request_firmware_nowait(). The compat_firmware_class module registers its own sysfs subsystem and as such also gets udev events sent through a separate subsystem. Because of this a new udev rules file is required and provided. - -<h1>Research</h1> - -Active research is ongoing which could enhance automatically backporting the Linux kernel further. For details please read up on: - - * [http://www.diku.dk/~julia/andersen_ase08.pdf Jesper Andersen & Julia L. Lawall - Generic Patch Inference] - * [http://coccinelle.lip6.fr/ Coccinelle spatch] - -Consider one set of diffs that can be read by spdiff to produce an spatch. This could in theory allow us to backport <b>all</b> functionality on a kernel if only two or three sets of files were patched and interpreted by spdiff. - -<h1>Contributions</h1> - -Contributions to compat follow the same mechanisms as used in the Linux kernel, this means you should provide as Singed-off-by tag as documented on the [http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html Developer's Certificate of Origin 1.1]. - -<h1>Submitting patches</h1> - -compat and compat-drivers contributions follow the contribution model implemented by the Linux kernel. Patches or pull requests for compat and compat-drivers must have be signed-offed. If you don't sign off on them they will not accepted. This means adding a line that says "Signed-off-by: Name email" at the end of each commit, indicating that you wrote the code and have the right to pass it on as an open source patch. For exact definition of what the Signed-off-by tag is you can read the definition of the "Developer's Certificate of Origin 1.1", which you can read here: - -http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html - -You can send patches as follows: - -<pre>To: mcgrof@kernel.org</pre> -<pre>Cc: backports@vger.kernel.org</pre> -<pre>Subject: compat: foo</pre> - -<h1>License</h1> - -The compat module and code is all licensed under the same license as the Linux kernel and is considered a complete derivative work of the Linux kernel. For more information refer to the COPYRIGHT file.
\ No newline at end of file diff --git a/wiki/Documentation_integration.mediawiki b/wiki/Documentation_integration.mediawiki deleted file mode 100644 index e2fe176..0000000 --- a/wiki/Documentation_integration.mediawiki +++ /dev/null @@ -1,177 +0,0 @@ ---- -title: Documentation/integration ---- - -The backports project first started out by supporting making releases as [[Documentation/packaging|packaged tarballs]] whereby users can compile future versions of device drivers on older versions of Linux. As of tag backports-20141114 (first release branch will be based on origin/linux-3.19.y) backports supports '''kernel integration''' support. - -Kernel integration support allows you to: - -* '''atomically integrate''' future versions of device drivers -* apply required patches to backport them -* add hooks into kconfig to make them visible and usable -* deal with conflicts with older versions of these same drivers - -By supporting kernel integration, the backports project can now support enabling use of automatically backported subsystems and drivers on older kernels without requiring modules, everything can be '''built-in'''. - -<h2>Kernel integration summary</h2> - -In order to understand how kernel integration works familiarize yourself first [[Documentation/backports/hacking#Backports_development_flow|the backports development flow]] and [[Documentation/backports/hacking#Backports_git_tree_tags_and_branches|the backports git tags and branches]]. Usage of integration involves a ''kernel source'' and ''kernel target''. As with [[Documentation/packaging|backports packaging]] each tag has a respective upstream linux-next or linux stable respective tag which can be used as a ''kernel source''. The ''kernel target'' is a kernel tree of an older Linux release. For example if you want to integrate linux-next tag next-20141114 onto v3.15 you may want will want to use the tag backports-20141114 on the backports tree; the ''kernel source'' will be the linux-next tree tag next-20141114 (you can either reset the tree to that tag or use --git-revision tag to ./gentree.py) and the ''kernel target'' can be a linux git tree reset to the v3.15 tag. Each backports tag should be usable on all older supported kernels, this means you could have used as a ''kernel target'' a tree set to v3.0, v3.1.. up to today's latest release. - -<h2>Kernel integration use case</h2> - -'''Kernel integration''' is an advanced technique part of the backports project which should make automate the task of completely integrating a specific version of a device driver based on future / current upstream releases on older kernel trees. This is typically more important where products are being supported using old kernels but the required device driver is only available on a future version of Linux. Linux distributions which want to make releases based on slightly older version of Linux but need newer device drivers can also make use of this. Kernel integration support enables two new important features when using backports now: - -* built-in support (non modular) -* support for backporting features / components which the kernel only supported via built-in - -''How you use integration is up to you'', we provide tools to help with the process and at least for now '''make the first integration seamless'''. If you are resetting your tree every time you base your release on a new version of Linux you can use kernel integration to bump the supported device drivers up to the latest known stable release for example, thereby minimizing the amount of manual cherry picks required. The backports project only provides patches required to backport device drivers from a future version of Linux down to a specific release of Linux, although it does not maintain specific cherry picks outside of what is required to get the driver to work on older versions of Linux specific cherry picks can easily be aggregated on top of the carried set of patches. Use of backports for cherry picking it outside of the scope of support for the project but it simply consists of adding your patches onto the patches/ directory, either in legacy patch form or SmPL form, if this strategy is followed its recommended a new directory be used to track these patches and a way to know if they need to be carried over when moving to a new version of Linux / backports. - -<h2>Integrating a release</h2> - -The same script that is used for generating [[Documentation/packaging|backports packaged tarballs]] is used for kernel integration, gentree.py as there is a lot of code to share between both strategies. An example will be provided of how to integrate a future set of supported device drivers onto an older release tree of the Linux kernel. Any kernel tree >= 3.0 can be used as a ''kernel target'', the ''kernel source'' will be any tag after next-20141114 from linux-next and backports-20141114, as well as any Linux release after v3.19 using the respective backports stable branch for that release. The example we provide here integrates linux-next next-20141114 onto the Linux kernel tree reset to v3.15. - -To backport linux-next tag next-20141114 onto a Linux tree reset to v3.15 do, you must first ensure your backports tree is on backports-20141114 and then you can use: - - $./gentree.py --integrate --clean --gitdebug --git-revision next-20141114 ~/linux-next/ ~/linux/ - -This assumes that ~/linux/ is a git tree reset to the tag v3.15. This should take 1-2 minutes on a typical laptop / system. - -<h2>Kernel integration menuconfig</h2> - -After kernel integration you will see an entry like the one that follows on your 'make menuconfig' menu: - - [*] Backport Linux next-20141114-0-gd7e5a72 (backports backports-20141114-0-gded96b2) ---> - -[[File:Integration-menuconfig-start-3.15.png]] - -Under that menu you will see device drivers taken from linux-next tag next-20141114 and backported for you for use on v3.15. Enabling one device driver from a future version of Linux will require using only the latest version of the subsystem modules and other subsystem drivers. For example enabling cfg80211 and mac80211 from a future version of Linux will require you to only use future version of the respective device drivers. In order to enable the backported version of 802.11 drivers for example, you will have to enable first: - -<pre> - Networking support --> - Wireless --> -</pre> - -But under that menu disable all options. You will also need to now disable all 802.11 device drivers under (including CONFIG_WLAN) - -<pre> -Device Drivers ---> - Network device support ---> - [ ] Wireless LAN ----> -</pre> - -Now to enable 802.11 drivers jump to the backports submenu to now enable backported 802.11 drivers: - -<pre> - Backports --> - cfg80211 - mac80211 - Wireless LAN ---> - etc -</pre> - -You should now be able to enable any backports 802.11 device driver. Here's an example of full list of things you should see as of backports-20141114: - -[[File:Integration-menuconfig-drivers-3.15.png]] - -<h2>Audit kernel integration work</h2> - -Backports takes advantage of the previously supported --gitdebug flag for backport packaging in order to allow atomically tracking each atomic operation done when integrating all pieces of software from a future kernel to be supported on the ''target kernel''. For this particular integration, for example, it generates 92 commits. Ordered with the last commit first, these are: - -<pre> -$ git log v3.15~1.. --pretty=oneline -c066a39ad047947dafbc4418ff10dadd3ad07921 apply integration patch 001-enable-backports/0001-enable-backports-built-in.patch -000658cb018b781a08f174df3b5521b4385de759 hooked backport to top level Kconfig -d78c278758a81a16d5f7d3dfd0782600cf5376ed disable unsatisfied Makefile parts -e9d0f1fbfa6ce67feb1cff978bca40875277c47f add kernel version dependencies -f5b738e65019fd51201688e3080d71c9ad5e8477 disable impossible kconfig symbols -7de02203cd5a501bd69ea6c98eac126f1eb57b61 rename config symbol / srctree usage -f70c7f185ca87d2f52ad72732fda3f1fa70f0891 add (useful) defconfig files -697ece5caa7e38f3ef34811b4440637c6d8fa080 convert select to depends on -9bf64ce6127ef2abfa2463b1063a236863e14f7b adjust backports config symbols we port -b42e104c94ab0d30967dc5a31062335370b10a4f prune Kconfig tree -b52feb5fef8a887170eee04383e1986a153dccd9 verify sources on top level backports Kconfig -61d328ea565d3f03573b3a99dd3f3896efef727b generate kernel version requirement Kconfig file -900a22cca078a7a5793d7c3b2bb444066677539a apply backport SmPL patch collateral-evolutions/network/0031-sk_data_ready.cocci -ef6d48763eb52f65bcd0eabfd8ae9e9f16e5074f apply backport SmPL patch collateral-evolutions/network/0019-usb_driver_lpm.cocci -f14786714aff5c94ae49b6f0acc3af095f5fbf5f apply backport SmPL patch collateral-evolutions/network/0001-netlink-portid.cocci -9f88ec9628756758132fe7c189c82575127ed838 apply backport SmPL patch collateral-evolutions/generic/0001-group-attr/0002-group_attr_bus.cocci -93b0c05507001c338a4efc4d9f3699bfee286b85 apply backport SmPL patch collateral-evolutions/generic/0001-group-attr/0001-group_attr_class.cocci -be4fb7cdd961f3d336086253712381190d7f8316 apply backport patch collateral-evolutions/network/0049-no-pfmemalloc/igb.patch -d048c6abbaa4a17eeed64b75bf071dd83e575959 apply backport patch collateral-evolutions/network/0048-no_ndo_xmit_flush/igb.patch -c606a1727efa4fb0aaddb103fc0ace9e7340110d apply backport patch collateral-evolutions/network/0047-write_iter/bluetooth.patch -09a99346f1625aa0ce203de1134145be750d6dc7 apply backport patch collateral-evolutions/network/0046-mmc_rescan_entered/mwifiex.patch -9fb5b3de864d7fa049ff0e304e2c04931351adbd apply backport patch collateral-evolutions/network/0044-no_user_ns_in_net/ieee802154.patch -a79ce2806e10dc7ac13c0f0f00b43e08454a8c29 apply backport patch collateral-evolutions/network/0043-ndo_set_vf_rate/igb.patch -01de0cf6c40dae21404e5fcf0f0e622a7cc4364c apply backport patch collateral-evolutions/network/0042-pci_error_handlers/ngene.patch -f6a578dd6050dfb76b0c9e79b6e7e9fc1539697f apply backport patch collateral-evolutions/network/0042-pci_error_handlers/igb_pci_error_handlers.patch -69c972277125ce73ca22d5436311c5718449669d apply backport patch collateral-evolutions/network/0042-pci_error_handlers/atl1e.patch -87664cd587c14623c386ac583f7dfebedfd07469 apply backport patch collateral-evolutions/network/0042-pci_error_handlers/atl1c.patch -102f85e8d0b698528bd05adb1fad73004330ca9e apply backport patch collateral-evolutions/network/0042-pci_error_handlers/alx.patch -807d99b29a7186a398a3895df8c22911a46c5686 apply backport patch collateral-evolutions/network/0041-devm_hwmon_device_register_with_groups/igb-devm_hwmon_device_register_with_groups.patch -5e399498c589af4f144a78590d6303bada824183 apply backport patch collateral-evolutions/network/0040-ethtool_cmd_mdix/igb_ethtool_cmd_mdix.patch -041bb3abc060f04b0924e2c313479430257a0b8a apply backport patch collateral-evolutions/network/0039-ethtool_rxnfc/igb_rxnfc.patch -91bc49e12a2c302eb6e264eeb6944806caaa2714 apply backport patch collateral-evolutions/network/0038-ethtool_rxfh_indir/igb_rxfh_indir.patch -24fe54661213f4d82642dd7eaeae92314ee2ca55 apply backport patch collateral-evolutions/network/0037-ethtool_get_module/igb_get_module.patch -5a8c3bf1e10a9dcd31f50c3acd3a42d6a4a5b3ac apply backport patch collateral-evolutions/network/0036-ethtool_eee/igb_ethtool_eee.patch -237294691d58ec7ff6e41fc6f48587bd7d6c1f7c apply backport patch collateral-evolutions/network/0035-skb_no_fcs/igb_skb_no_fcs.patch -fb1cb2e44c89847b04e2d021328ea548cbe05fa6 apply backport patch collateral-evolutions/network/0034-ndo_set_vf_spoofchk/igb_ndo_set_vf_spoofchk.patch -f24bb572ee690b3aac0e89fa2d04888e8a036d7c apply backport patch collateral-evolutions/network/0033-ndo_vlan_rx_vid/igb_ndo_vlan_rx_vid.patch -3878c64fc254f7acbd86e3539bf330b04730abb8 apply backport patch collateral-evolutions/network/0033-ndo_vlan_rx_vid/cdc_mbim.patch -c888e6433a8b2ac7c3e0058a4936836ab15c3f6d apply backport patch collateral-evolutions/network/0032-sriov_configure/igb_sriov_configure.patch -59ac89cb5e1fa8876555639bab09bc4a97673db5 apply backport patch collateral-evolutions/network/0030-qdisc_tx_busylock/ieee802154.patch -506736ea6f59fed1d323f77cf03915ebc6df3358 apply backport patch collateral-evolutions/network/0030-qdisc_tx_busylock/bluetooth.patch -5131db4cbec4ac8d7a6fb69246910644e0a8087d apply backport patch collateral-evolutions/network/0029-struct_hid_ll_driver-extensions/net_bluetooth_hidp_core.patch -9575c214edcc921e75910b881d3db6a69cd4b577 apply backport patch collateral-evolutions/network/0028-select_queue/mwifiex.patch -eafd9157010633a1cc7b025382b72f9bea8bfe8b apply backport patch collateral-evolutions/network/0028-select_queue/mac80211.patch -4b7d5be3639ec2178a398c6a0730a8a9098f067e apply backport patch collateral-evolutions/network/0027-genl-const/nl80211.patch -2283432684181d75e6288b2bd4d9f502c713087d apply backport patch collateral-evolutions/network/0027-genl-const/nfc.patch -e5fec49c6b5c59dffe06f11a099e8df2c38de2cd apply backport patch collateral-evolutions/network/0027-genl-const/ieee802154.patch -7b0bd1c47c0a22240593c3860ea78e87310531db apply backport patch collateral-evolutions/network/0027-genl-const/hwsim.patch -3156a48fc2aa1eb028d5074d0f15f02a2a784366 apply backport patch collateral-evolutions/network/0026-ipv6_stub/cdc_mbim.patch -ab5ca0e7db55e7a68bae27c278dc159be531caf7 apply backport patch collateral-evolutions/network/0025-usb-sg/usbnet.patch -18634861a944029a6623f5dc582482d7fdd87bba apply backport patch collateral-evolutions/network/0024-led-blink-api/mac80211.patch -6895c3c9fefe90302577ccc0207e574dab5db4fb apply backport patch collateral-evolutions/network/0022-define-tracing/wil6210.patch -61b12eb789add8ea4f42343ba5754a2003f9ff85 apply backport patch collateral-evolutions/network/0022-define-tracing/cfg80211.patch -4d362e9144e6189248976e83b797e93b5be2210a apply backport patch collateral-evolutions/network/0022-define-tracing/ath6kl.patch -a7a3cebf434a294ef089823eedf7c2db8b41a042 apply backport patch collateral-evolutions/network/0021-umode_t-api-change/ath10k.patch -a25e701fe08b1f124307c17cfa1eb1879b26693d apply backport patch collateral-evolutions/network/0020-tty-termios/net_bluetooth_rfcomm_tty.patch -829c2477a533e03c8df4f64d60d3acbc260f2090 apply backport patch collateral-evolutions/network/0020-tty-termios/drivers_bluetooth_hci_ath.patch -4793ad2d27a5a98b99f1af0cc4369f4d2dc67a78 apply backport patch collateral-evolutions/network/0018-pv-trace-fixes/net_mac80211_trace.patch -cc3fcdfcd106be170937111f5b1e9282ea8b2f43 apply backport patch collateral-evolutions/network/0018-pv-trace-fixes/drivers_net_wireless_iwlwifi_iwl-debug.patch -77b4d3a92296542ada9af173729c29ff8edaa4f0 apply backport patch collateral-evolutions/network/0017-get_ts_info/igb_get_ts_info.patch -3a1b78fee0ed903f167f2038ce3f7b34b80fff31 apply backport patch collateral-evolutions/network/0017-get_ts_info/drivers_net_usb_usbnet.patch -7af04292e12cd6a3bd4933cbc2db33f678935985 apply backport patch collateral-evolutions/network/0017-get_ts_info/cdc_ncm.patch -c9c75a56434fa88c3b5387964d390c957109bb0e apply backport patch collateral-evolutions/network/0016-libertas-olpc-ec-wakeup/drivers_net_wireless_libertas_if_usb.patch -63959daeafbac9ff38dbc847cbbb9a61501be851 apply backport patch collateral-evolutions/network/0015-rename_pm_qos_request/drivers_net_wireless_ipw2x00_ipw2100.patch -5e7f8f9b32dcb984445bde43f69656c97b31c7e7 apply backport patch collateral-evolutions/network/0014-netlink_seq/net_wireless_nl80211.patch -35d5785bfdcdf579493f3076f3ac9bc397ce9597 apply backport patch collateral-evolutions/network/0013-fix-makefile-includes/net_wireless_Makefile.patch -5adbb25691d4745f5f47ffc493bfd32a063480ca apply backport patch collateral-evolutions/network/0013-fix-makefile-includes/bluetooth.patch -2258d123aec87c0a11515130d9297587633fdafc apply backport patch collateral-evolutions/network/0012-driver-quirks/drivers_net_wireless_cw1200_sdio.patch -d1f6fc792d3fba9ee20f31562c04e34af0f6daab apply backport patch collateral-evolutions/network/0011-mac80211-disable-tx-status/net_mac80211_tx.patch -a146dcd4c0db925dc8a3fec1ee93074b0a192c67 apply backport patch collateral-evolutions/network/0010-add-wext-handlers-to-netdev/net_wireless_core.patch -5e1b6f56f043608ee68cef35d7deda383b78fd01 apply backport patch collateral-evolutions/network/0008-net-user-ns.patch -5000b38d3dcc9434b19eaccde8aca21f0b271e12 apply backport patch collateral-evolutions/network/0007-lowpan-inet_frag_lru_move.patch -2ae7bbbdb7eb2c02058327dfc057ad841aede913 apply backport patch collateral-evolutions/network/0006-ieee802154-6lowpan-namespace.patch -fc28048373ae3c6637cedab606919e7817f6ffad apply backport patch collateral-evolutions/network/0005-disable-usb-net-asix.patch -50e3e5f2151ed76aef9a1ac7352959a806e55e6f apply backport patch collateral-evolutions/network/0004-disable-wext-kconfig.patch -98b551a9316154702270ac7164916e49180c0046 apply backport patch collateral-evolutions/network/0003-cfg80211-wext-padding/net_wireless_core.patch -0f5f1ae4483b16f187f074b676d19212dab814f8 apply backport patch collateral-evolutions/network/0003-cfg80211-wext-padding/include_net_cfg80211.patch -8cfeb3d0bdec62cccb0cf76f44ca2e7e5c5e9ff0 apply backport patch collateral-evolutions/network/0002-disable-dump-adjust-on-old-kernels.patch -166003e19c7a9ff28a43004ad27d68af3a3aace0 apply backport patch collateral-evolutions/media/0004-missing-include/ir-hix5hd2.patch -f1152ca58d2400a956a969ae88b80c35c449d6dc apply backport patch collateral-evolutions/media/0004-missing-include/hackrf.patch -94f80b0f595162569b70684d7ed87612b31a764f apply backport patch collateral-evolutions/media/0004-missing-include/airspy.patch -6d974050060a1d74d61b1927ac0f18ca0267e3d5 apply backport patch collateral-evolutions/media/0003-devnode_param_type/rc.patch -2678364bc96c15c9e39bdf901f60fb8bef5d9851 apply backport patch collateral-evolutions/media/0003-devnode_param_type/dvb-core.patch -04361b3134ed2cd078920eb651ec1a15c038a307 apply backport patch collateral-evolutions/media/0003-devnode_param_type/ddbridge.patch -b0a68f9e7b235ad44f64686a7657d65ededaeb87 apply backport patch collateral-evolutions/media/0002-no_dmabuf/v4l2.patch -102162ef4bda228fc2de08826f8c304001503b67 apply backport patch collateral-evolutions/media/0001-dma_mmap_coherent-revert.patch -780d84bd410b4252cfc4df431b5c0e8c6133fcef apply backport patch 0000-upstream-backport-changes/0005-uapi-compromise/mwifiex.patch -6a77c4dc3c16907373648a774678c0bf63b1f786 Add automatic backports -6e8820dfdd11eb2ef361f344ece8170e6776a151 modify top level backports/Kconfig with backports identity -c1e39709cfde12068fa3b693d71f72fc536d4df4 verify sources for automatic backports -9b34df472df8dbf0c3b518eab7a5e378c966fa3f Add driver sources -5b8285fa632ad085753da8e930c0ec2275c191ff Copied backport -1860e379875dfe7271c649058aeddffe5afd9d0d Linux 3.15 -</pre> - -[[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].
\ No newline at end of file diff --git a/wiki/Documentation_packaging.mediawiki b/wiki/Documentation_packaging.mediawiki deleted file mode 100644 index 36867d1..0000000 --- a/wiki/Documentation_packaging.mediawiki +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: Documentation/packaging ---- - -The backports project makes release of two types of '''packages''' which provides device drivers from future versions of Linux usable on older Linux kernel releases. - -<h2>Backports package release types</h2> - -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. - -<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].
\ No newline at end of file diff --git a/wiki/IRC.mediawiki b/wiki/IRC.mediawiki deleted file mode 100644 index b7f6297..0000000 --- a/wiki/IRC.mediawiki +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: IRC ---- - -Join us: - -irc.freenode.net #kernel-backports - -Do not ask for permission to ask a question in IRC, just ask it with all the information you have and wait for someone answering. - - -[[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].
\ No newline at end of file diff --git a/wiki/License.mediawiki b/wiki/License.mediawiki deleted file mode 100644 index 5dbf5ca..0000000 --- a/wiki/License.mediawiki +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: License ---- - - -<h2>Linux kernel backports license</h2> - -This work is a subset of the Linux kernel as such we keep the kernel's -Copyright practice. Some files have their own copyright and in those -cases the license is mentioned in the file. All additional work made -to building this package is licensed under the GPLv2. - -<h2>Backporting preference for EXPORT_SYMBOL_GPL() and proprietary drivers</h2> - -The Linux kernel backports framework was designed by intent since its inception *only* for upstream -Linux kernel drivers to avoid excuses about the difficulty to support upstream -Linux kernel development while also supporting users on older kernels. To -ensure the intent is respected currently all symbols that we do work on to -backport are exported via EXPORT_SYMBOL_GPL() as we do work to backport them -for the supported kernels. By using EXPORT_SYMBOL_GPL() we make it *clear* that -if you use the backported symbols your software *is* considered derivative -works of the Linux kernel. - -<h2>Developer's Certificate of Origin 1.1</h2> - -Linux backports relies on the 'Developer's Certificate of Origin 1.1', for more details refer to [https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking#Sending_patches the submitting patches documentation].
\ No newline at end of file diff --git a/wiki/Mailing_list.mediawiki b/wiki/Mailing_list.mediawiki deleted file mode 100644 index bf9c0f1..0000000 --- a/wiki/Mailing_list.mediawiki +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Mailing list ---- - -Mailing list: [http://marc.info/?l=linux-backports (archives)] [[#Subscribing to backports|(subscribe)]] [mailto:backports@vger.kernel.org (send)] - -= Topics = - -Contact the '''backports@vger.kernel.org''' mailing list with: - -* patches -* bug reports -* questions regarding the backports project - -= Subscribing = - -To subscribe send an e-mail to ''majordomo@vger.kernel.org'' with anything on the subject and with this on the body of the e-mail: - -<pre> -subscribe backports -</pre> - -You will receive an e-mail from Majordomo telling you what other steps you need to follow to subscribe. - -[[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].
\ No newline at end of file diff --git a/wiki/Main_Page.mediawiki b/wiki/Main_Page.mediawiki deleted file mode 100644 index e2c1242..0000000 --- a/wiki/Main_Page.mediawiki +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: Main Page ---- - -__NOTOC__ - -The ''Backports Project'' enables old kernels to run the latest drivers. - -"''Backporting''" is the process of making new software run on something old. A version of something new that's been modified to run on something old is called a "''backport''". - -The Backports Project develops tools to automate the backporting process for Linux drivers. These tools form the ''backports'' suite. - -= History = - -The Backports Project started in 2007 as ''compat-wireless''. It was renamed to ''compat-drivers'' as the project's scope broadened beyond just wireless network drivers. Nowadays, the project is known simply as ''backports''. - -As of the 3.10-based release, over 830 device drivers had been backported. - -Recent versions of backports support mainline kernels back to version 3.0. The older backports-3.14 supports all kernel versions back to version 2.6.26. - -= Resources = - -* [[Releases|Package releases: (download)]] -* Daily snapshots: [http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git (linux-next)] [http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git (linux-stable)] -* [https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git git repository] -* [https://bugzilla.kernel.org/enter_bug.cgi?product=Backports%20project Bugzilla bug tracker:] [[Bugs#Bugzilla|(notes)]] - -= Documentation = -* [[license|Linux kernel backports license]] -* User documentation -** [[documentation|Overview]] -** [[Documentation/packaging|Package release mode]] -** [[Documentation/integration|Kernel integration mode]] -* [[Documentation/backports/hacking|Developer documentation]] -* [[Bugs|Reporting bugs & security vulnerabilities]] - -== Papers == - -* [http://coccinelle.lip6.fr/papers/backport_edcc15.pdf Increasing Automation in the Backporting of Linux Drivers Using Coccinelle - Luis R. Rodriguez, Julia Lawall] (12 pages) - -== Videos == - -* [https://www.youtube.com/watch?v=ZXATzae7eng Automatically Backporting the Linux Kernel - Luis Rodriguez] (54 minutes) -** SUSE Labs Conference, České Budějovice, October 2014 -* [https://www.youtube.com/watch?v=buZrNd6XkEw An Introduction to Coccinelle Bug Finding and Code Evolution for the Linux Kernel - Julia Lawall] (1 hour 58 minutes) -** SUSE Labs Conference, České Budějovice, October 2014 -* [https://www.youtube.com/watch?v=lvFXQ6zyHCg An Update on the Linux Backports Project - Luis R. Rodriguez, Qualcomm Atheros] (43 minutes) -** LinuxCon and CloudOpen Conference, New Orleans, October 2013 - -= Community = - -* [[Mailing list]]: [http://marc.info/?l=linux-backports (archives)] [[Mailing list|(subscribe)]] [mailto:backports@vger.kernel.org (send)] -* [[IRC]]: server "irc.libera.chat:6697" (TLS), channel "#kernel-backports" -* [[Social media|Twitter]]: @LinuxBackports -* [[Social media|identi.ca]]: @LinuxBackports -* [[Meetings]] -* [[Documentation/backports/hacking|Contributing]] - -[[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].
\ No newline at end of file diff --git a/wiki/Meetings.mediawiki b/wiki/Meetings.mediawiki deleted file mode 100644 index dfbecd1..0000000 --- a/wiki/Meetings.mediawiki +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Meetings ---- - -= Backport project meetings = - -At times we may meet. This page is dedicated towards documenting any meetings that have taken place or will take place. - -= Linux Plumbers 2013 - New Orleans = - -There will be a talk about backporting at LPC 2013. - -= Sept 4 2012 meeting = - -On Sept 4, 2012 we had our first [https://plus.google.com/events/cbsid8cbvp61sv4nmjfgftsv9f0/101487746899672598413 G+ Linux kernel backports hangout ] at. This took place at: - - * 08:00:00 p.m. Tuesday September 4, 2012 in GMT - * 01:00:00 p.m. Tuesday September 4, 2012 in US/Pacific - * 04:00:00 p.m. Tuesday September 4, 2012 in US/Eastern - * 10:00:00 p.m. Tuesday September 4, 2012 in Europe/Berlin - * 11:00:00 p.m. Tuesday September 4, 2012 in Europe/Helsinki - * 11:00:00 p.m. Tuesday September 4, 2012 in Asia/Jerusalem - * 01:30:00 a.m. Wednesday September 5, 2012 in Asia/Calcutta - -Recording of the session: - -http://www.youtube.com/watch?v=FZqDz7sXZiQ - -Agenda: - - * Current project objectives: - * 802.11, Bluetooth, Ethernet, drm drivers - * Vanilla kernels are supported but also now: - * RHEL6 - * Coccinelle SmPL - 0001-netdev_ops.patch -- collateral evolution work - * Build server for helping with testing patches - * git tree mirroring on git.kernel.org - * Daily linux-next based snapshots via kernel.org - * Public facing releases via kernel.org as of v3.7-rc1 - * Things to look out for: - * linux-firmware.git updates - script install target ? - * Module key signing & UEFI - Fedora 18 Alpha release schedule for 2012-09-11 - * Understanding the implications of a stable extra version release update: ee9c8a04 backported to v3.4.6 - -[[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].
\ No newline at end of file diff --git a/wiki/Releases.mediawiki b/wiki/Releases.mediawiki deleted file mode 100644 index 20d3740..0000000 --- a/wiki/Releases.mediawiki +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Releases ---- - -= Latest releases = - -All these releases should work against the same kernel major version and all older versions till 3.10 for backports versions till 5.10. Later versions of backprots should work with kernel versions down to version 4.4. -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v6.1.97/backports-6.1.97-1.tar.xz backports-6.1.97-1.tar.xz] -** SHA256: 8e9ae2d02f373252dd61f5c6a81c88eec67ca773464d9ef3d844752dc6775540 -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.15.153/backports-5.15.153-1.tar.xz backports-5.15.153-1.tar.xz] -** SHA256: eaa24df968c79385c57707068a209fb1ea43271b573f24885805ae96a58ee3a8 -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.14.13/backports-5.14.13-1.tar.xz backports-5.14.13-1.tar.xz] -** SHA256: 042aef20caf17ef649502d5f2e744a7676abe7faed18de83c96f37bc029635fe -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.13.19/backports-5.13.19-1.tar.xz backports-5.13.19-1.tar.xz] -** SHA256: 1eb761c1664d59a0a2d52847f240c9d02fc2e56fb27d862d2949bfb275187eef -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.12.19/backports-5.12.19-1.tar.xz backports-5.12.19-1.tar.xz] -** SHA256: 4233002bcf26237783cd517d93c27807e534234cef64def7e550c5f06b779d18 -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.11.22/backports-5.11.22-1.tar.xz backports-5.11.22-1.tar.xz] -** SHA256: 35c23dd182711a3a6f671a673c2e0ace2ffdd25bbd1fb917e428d04924141299 -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.10.157/backports-5.10.157-1.tar.xz backports-5.10.157-1.tar.xz] -** SHA256: 1ce937c49f2b39be00768fba83e214aad6612d469c92ccd06dc17b14e6cf3a64 -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.9.12/backports-5.9.12-1.tar.xz backports-5.9.12-1.tar.xz] -** SHA256: 8cf3f23152a787eeec2df1d7b38a559b0d89bdc823d9ac99175a4eb76d2b619e -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.8.18/backports-5.8.18-1.tar.xz backports-5.8.18-1.tar.xz] -** SHA256: f04a8172423c6a945fc7d9844b04f33fda9ae574e552f8f18ee3bdfcfb494563 -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.7.5/backports-5.7.5-1.tar.xz backports-5.7.5-1.tar.xz] -** SHA256: 200312d46eb6a94676f611af6baebbffc5cbf3b7dd75e72a69c767704c37b571 -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.6.8/backports-5.6.8-1.tar.xz backports-5.6.8-1.tar.xz] -** SHA256: 547c5e17b9e23dd23cdf4d617a7550b80869e02114a7d404911c5ae928ae1da5 -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.5.19/backports-5.5.19-1.tar.xz backports-5.5.19-1.tar.xz] -** SHA256: 9dd9153df6082eaa079144193a3fab79d200942e1a2a1a80e032c9667b7b92a6 -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.4.56/backports-5.4.56-1.tar.xz backports-5.4.56-1.tar.xz] -** SHA256: 6030c2427e04f976cf53330087d0fdbb60ead7e1fecbd85e6f8e97ec0ed9a2eb -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.3.6/backports-5.3.6-1.tar.xz backports-5.3.6-1.tar.xz] -** SHA256: 16ded706945999543a73e2349d36b8003eeb2b097970ea1ad80344b9f56393a3 -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.2.8/backports-5.2.8-1.tar.xz backports-5.2.8-1.tar.xz] -** SHA256: d1ac22a9b7536f730a992292fb29c70355ffc42ea9f58610010ea196dc69b2e3 -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.1.16/backports-5.1.16-1.tar.xz backports-5.1.16-1.tar.xz] -** SHA256: b5adc5d458734b9231e81bcf03af2fb1bf2e289a87f1551a4f02bdf3ba053fb8 -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.0.5/backports-5.0.5-1.tar.xz backports-5.0.5-1.tar.xz] -** SHA256: 9fe6eeaf2043a6eadbc5a13277b0ac62905451af55d7afaa6ac2d91a3aa8c298 -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v4.20.17/backports-4.20.17-1.tar.xz backports-4.20.17-1.tar.xz] -** SHA256: c7efc87babef35c08251a04cb26ffd683026d1365f5bbf8226c9e22462c41592 -* [https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v4.19.221/backports-4.19.221-1.tar.xz backports-4.19.221-1.tar.xz] -** SHA256: 343f54b21ddda4bc79c0457a7fa88356d430b802f86194abc20fe09c12559b05 - -All releases: https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/
\ No newline at end of file diff --git a/wiki/Social_media.mediawiki b/wiki/Social_media.mediawiki deleted file mode 100644 index 4ebc5cb..0000000 --- a/wiki/Social_media.mediawiki +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Social media ---- - -= Linux backports social media = - -Apart from making announcements on the mailing lists you can also subscribe to the following social media outlets to get updates: - - * [https://twitter.com/LinuxBackports @LinuxBackports on Twitter] - * [http://identi.ca/linuxbackports @LinuxBackports on identi.ca] - -[[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].
\ No newline at end of file |
