Documentation/backports/hacking

From Driver Backports Wiki
(Difference between revisions)
Jump to: navigation, search
(Add a note about this page being outdated.)
 
(23 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
'''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 =
 
= 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].
 
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 =
 
= Git trees you will need =
  
backports 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.
+
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.
 
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.
This is now in one repository [https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git backports.git] and not spitted over two any more.
+
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.
 
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 =
 
= Generate new release =
Line 17: Line 63:
 
<code>
 
<code>
 
<pre>
 
<pre>
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/backports.git
+
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
 
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
 
</pre>
 
</pre>
Line 35: Line 81:
 
= Adding new driver =
 
= 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/mcgrof/backports.git/commit/?id=a42aa4d474e5859164a00bf451970fb58b676fcf].
+
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.  
 
You should target the master branch of the backports repository.  
Line 42: Line 88:
 
# 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 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/Makefile.kernel</code> if needed (just needed for new substems)
# Add reference to the newly added driver directory in <code>backport/Kconfig</code> if needed (just needed for new subsystems)
+
# 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>
 
# 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>
 
# If the driver does not build on all kernel versions specify a minimum kernel version in <code>dependencies</code>
Line 54: Line 100:
 
= Backports Kconfig operation =
 
= Backports Kconfig operation =
  
Go read the [https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/tree/devel/doc/kconfig-operation backports kconfig operation] documentation.
+
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 =
 
= Backports Makefile operation =
  
Go read the [https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/tree/devel/doc/makefile-operation backports Makefile operation] documentation.
+
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 =
 
= Sending patches =
  
 
backports contributions follow the contribution model
 
backports contributions follow the contribution model
implemented by the Linux kernel. Patches or pull requests for backprots
+
implemented by the Linux kernel. Patches or pull requests for backports
 
must have be signed-offed. If you don't sign off on them
 
must have be signed-offed. If you don't sign off on them
 
'''they will not accepted'''. This means adding a line that says
 
'''they will not accepted'''. This means adding a line that says
Line 80: Line 126:
 
<code>
 
<code>
 
<pre>
 
<pre>
To: Luis R. Rodriguez <mcgrof@kernel.org>
+
To: hauke@hauke-m.de, mcgrof@kernel.org
 
CC: backports@vger.kernel.org
 
CC: backports@vger.kernel.org
 
Subject: [PATCH] backports: fix foo
 
Subject: [PATCH] backports: fix foo
Line 87: Line 133:
  
 
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].
 
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 =  
 
= Backporting preference for EXPORT_SYMBOL_GPL() and proprietary drivers =  
Line 95: Line 169:
 
ensure the intent is respected currently all symbols that we do work on 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
 
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
+
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
 
if you use the backported symbols your software '''is considered derivative
 
works of the Linux kernel'''.
 
works of the Linux kernel'''.
  
= TODO =
+
= Backporting more subsystems =
  
== DKMS support ==
+
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.
  
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?
+
= Generating backports stats =
=== Who's working on this ? ===
+
  
No one
+
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.
  
== make localmodconfig support ==
+
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:
  
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.
+
<code>
 +
cd linux-next
 +
git reset --hard next-20151218
  
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.
+
cd ~/backports/
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? ===
+
mkdir -p ~/build/
 +
rm -rf ~/build/backports-20151218
 +
./gentree.py --gitdebug ~/linux-next ~/build/backports-20151218
 +
</code>
  
No one.
+
Now go get the temporary backports stats tool and copy over the required binary and script:
  
== Module namespaces ==
+
<code>
 +
cd ~/
 +
git clone https://github.com/mcgrof/backports-cocci-stats.git
 +
cd backports-cocci-stats
 +
make
  
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:
+
cp gen-cocci-stats.sh ~/build/backports-20151218/
 +
cp clean ~/build/backports-20151218/
 +
</code>
  
<tt>
+
Now generate the stats, you should see something like this:
#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.
+
<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>
  
=== Motivations ===
+
Now say you wanted to generate stats for a newer release, say for stats based on linux-next tag next-20160122, you would do:
  
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.
+
<code>
 
+
cd ~/linux-next/
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.
+
git reset --hard next-20160122
 
+
=== Who's working on this? ===
+
 
+
No one.
+
 
+
== Non modular backport support ==
+
 
+
As it stands the backports project only supports providing backport updates of modules. That is your system gets updated drivers but if a core kernel component that is not modular is updated we can't provide an update for it unless we can technically extract that core kernel feature, map it in modular form and then have the backported version of the modules use a new namespace. The problem with doing this happens when a core kernel component is dependent upon another core kernel component that cannot be backported or extracted out.
+
 
+
There is hope however. The idea consists to not backport live kernels given that ksplice seems limited to what can be done for backporting purposes but instead to allow Linux distributions to pick a stable kernel, pick a backports release and have it merge into that kernel release. Typically Linux distributions cherry pick patches and deal with merge conflicts manually. The idea is to the stable kernel as a vanilla release and deal with the integration of new backported components using the backports framework. Just as you would build a kernel through ''make menuconfig'' upon kernel configuration time you'd then have present your vanilla kernel components and also backported features through a menu subsection. You'd then be able to build backported features as in-kernel or modular just as you would typically build a vanilla kernel.
+
  
See commit [https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/commit/?id=0935deabd1c7f95ab0ed07dd40291022c7822913 0935dea] for the hints supplied on how to deal with backporting core kernel features. The idea is you should be able to modify the in-kernel's init routine, add our own backport_init() in the series of init calls and throw onto it what we need from future kernels.
+
cd ~/backports/
 +
./gentree.py --gitdebug ~/linux-next/ ~/build/backports-20160122
  
This likely will require a separate script other than gentree.py, perhaps mergetree.py.
+
cd ~/build/backports-20160122
 
+
cp ~/backports-cocci-stats/gen-cocci-stats.sh .
== Motivation ==
+
cp ~/backports-cocci-stats/clean .
 
+
./gen-cocci-stats.sh
If possible this solution should provide an alternative for users / Linux distributions to cherry pick changes from a future kernel down to older kernels by providing full frameworks / subsystems. One clear benefit is the time reduced to provide a backport and complete and clear separation against what is on a vanilla upstream stable kernel.
+
mcgrof@ergon ~/build/backports-20160122 (git::master)$ ./gen-cocci-stats.sh
 
+
-----------------------------------------------------------------------------
=== Who's working on this? ===
+
Development and Maintenance efficiency metrics:
 
+
-----------------------------------------------------------------------------
Luis will try to dive to look into this August 19th - Sept 13th. With a simple proof of concept feature / driver.
+
    dev-efficiency   maint-efficiency diff-wc   diffstat     clean     SmPL-Patch
 
+
              0.4               2.6       13         2         5 0067-mdio-addr.cocci
== SmPL integration ==
+
          0.555556           2.33333       21         5         9 0065-ndisc_send_na-argument.cocci
 
+
              2.75                 8       64         22         8 0062-iff-no-queue.cocci
Typically patches may fail if hunk offsets are off by the allowed offset. We upkeep hunk offsets placements up to date by refreshing patches. We used to use quit refresh to refresh patch offsets but today we simply extract the new delta after application of a patch in which hunk offsets were off. At times however patches can fail to apply due to contexual changes within the patch. We are considering using SmPL to help with this.
+
          0.666667           1.88889       17         6         9 skb_no_xmit_more.cocci
 
+
          1.16667           2.79167       67         28         24 ptp_getsettime64.cocci
Its plausible that if you're hacking on the Linux kernel that you may have not yet heard of [http://coccinelle.lip6.fr/ coccinelle] or [http://coccinelle.lip6.fr/sp.php SmPL patches]. Truth is SmPL is already widely used across many subsystem in the Linux kernel and SmPL's usage even extends outside of the Linux kernel. The page that tries to document the [http://coccinelle.lip6.fr/impact_linux.php impact of SmPL on the Linux kernel] is clearly out of date and likely just needs to be automated with ''git grep''. The idea behind the need for SmPL came about studying and formalizing the concept of [http://coccinelle.lip6.fr/ce.php collateral evolutions] on the Linux kernel. Luis elaborates on his blog on how this can be used to help [http://www.do-not-panic.com/2012/08/optimizing-backporting-collateral.html optimize collateral evolutions]. While still theoretical, if we want to make backporting more efficient we need to start using SmPL soon. The work should consist of properly supplying expressions that summarize backporting collateral evolutions from patches from which SmPL could likely deduced or written manually. In order accomplish this each collateral evolution must first be atomically reduced as much as possible. We then will need to categorize backported collateral evolution and prioritize working on categories that we could likely infer SmPL from. As it stands patches which have been already reduced as much as possible have been annotated by using a four digit prefix. Patches which can likely be split up further remain with a two digit prefix.
+
          0.142857                 1       14         2         14 features_check.cocci
 
+
          1.18182           5.45455       60         13         11 0055-netdev-tstats.cocci
Patches that need to be reviewed are under the [https://git.kernel.org/cgit/linux/kernel/git/mcgrof/backports.git/tree/patches/collateral-evolutions patches/collateral-evolutions] directory. The way backports works -- any directory name can be used to separate patches into any logical form as required. Integration with SmPL can start with inferring SmPL from the few four-digit prefixed patches and subsequently writing a Python tool which would use the SmPL patch to patch kernel code. The first objective is to prove backporting transformations are equivalent by either using the old series of patches for a specific collateral evolution or by using its expression in SmPL form. A proof can be obtained by computing the sha256 delta on the tree with both approaches.
+
          1.55906           3.55118     451       198       127 0054-struct-proto_ops-sig.cocci
 
+
          0.666667           1.88889       17         6         9 no-pfmemalloc.cocci
=== Who's working on this? ===
+
          0.634146             1.4878       61         26         41 set_vf_rate.cocci
 
+
              3.75             10.625       85         30         8 igb_pci_error_handlers.cocci
Luis will try to dive to look into this August 19th - Sept 13th. With a simple proof of concept feature / driver. Luis hopes to further collaborate with Julia on this between October 16 - December 15.
+
          1.07692           4.23077       55         14         13 ethtool_cmd_mdix.cocci
 
+
          0.588235           1.23529       21         10         17     rxnfc.cocci
== Infer SmPL for patch hunks healing ==
+
          0.285714           1.53571       43         8         28 get_module.cocci
 
+
          0.285714           1.53571       43         8         28 ethtool_eee.cocci
If a collateral evolution does not yet have a formal SmPL expression to represent it and if SmPL inference is plausible it'd be great to infer SmPL on the fly as a patch fails to attempt fixing the patch. SmPL inference however is only possible today with a series of similar hunks, at least 2, across different set of offsets. SmPL hunk healing then should not be possible for addressing singular hunk collateral evolutions.
+
          0.714286           2.28571       16         5         7 skb_no_fcs.cocci
 
+
              0.25           1.59375       51         8         32 set_vf_spoofchk.cocci
=== Who's working on this? ===
+
          0.428571           2.85714       40         6         14 sriov_configure.cocci
 
+
          0.87037             2.7037     146         47         54 0031-sk_data_ready.cocci
Luis hopes to further collaborate with Julia on this between October 16 - December 15.
+
              4.4               17.9     179         44         10 genl-const.cocci
 
+
          7.11111           49.6667     447         64         9 0019-usb_driver_lpm.cocci
== Using the inverse of SmPL to backport ==
+
          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>
  
If Linux kernel development dealt with collateral evolutions with a strict SmPL form it is theoretically possible that one might be able to use the inverse of a patch to backport a collateral evolution. We need to prove / disprove this. Exceptions to this and corner cases should also be inspected.
+
= See also =
  
=== Who's working on this? ===
+
* [[Documentation/backports/hacking/todo|To-Do List]]
 +
* [[License]]
  
Luis hopes to further collaborate with Julia on this between October 16 - December 15.
 
  
 
[[File:88x31.png‎]] - This text is licensed under a [https://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 Unported License].
 
[[File:88x31.png‎]] - This text is licensed under a [https://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 Unported License].

Latest revision as of 05:24, 8 September 2017

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 To-Do List and a License.

Contents

[edit] 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 by optimizing backporting collateral evolutions.

[edit] Backports development flow

  1. The 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.
  2. 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.

[edit] 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 paper, in particular the sections:

  • 1A - A. The Linux kernel development model
  • 1B - A brief history of the Linux kernel backports project

[edit] 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 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 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, linux.git and 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.

[edit] 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.

[edit] 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

[edit] 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 [1].

You should target the master branch of the backports repository.

  1. Add directories and files that should be copied from the mainline kernel to copy-list
  2. 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.
  3. Add reference to the newly added driver directory in backport/Makefile.kernel if needed (just needed for new substems)
  4. Add reference to the newly added driver directory in backport/Kconfig.sources if needed (just needed for new subsystems)
  5. 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
  6. 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.

[edit] 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/.

[edit] Backports Kconfig operation

Go read the backports kconfig operation documentation.

[edit] Backports Makefile operation

Go read the backports Makefile operation documentation.

[edit] 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 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:

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.

[edit] 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 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>

[edit] 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.

[edit] 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.

[edit] 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, 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 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

[edit] See also


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

Personal tools