zydronium/documentation
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update KernelPolicy.md

Browse source 
sync with latest internal discussion
This commit is contained in:
Mark Brown 2016-06-15 11:52:20 +01:00 • committed by GitHub
parent aaac65a46d
commit 4f745c91dc
1 changed files with 6 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

18
Reference-Platform/KernelPolicy.md
View file

@ -1,7 +1,8 @@
## Why
The Reference Kernel is the combination of kernel features from the various Linaro segment groups and HW enablement branches for each of the supported platforms. It focuses on a mainline version of the kernel containing features that aren't merged into mainline yet.
The end result, members of Linaro will contribute to a kernel branch that incorporates the activities and development of all members. The topics will be targeted towards tip, and rebased once the kernel has moved from -rc to stable. As in, if the current -rc is for 4.4, then all topics will be based on that kernel. Once the 4.4 kernel is released, all patches that were not accepted into the kernel release, will be rebased to the next developement kernel. In the case of this example, rebase from 4.4 to 4.5.
The reference platform kernel will provide a common tree collecting Linaro-relevant platform support and other features that are actively being upstreamed in order to support integration testing, provide platform support for the reference platform and track upstreaming efforts. A single tree will be maintained that merges relevant topics.
Some reference platforms may choose to add additional, out of tree code that does not meet the requirements for the RPK when building the kernels that they use.
See [Responsibilities](#Responsibilities) on how to get your patches into RPK.
@ -12,16 +13,9 @@ See [Responsibilities](#Responsibilities) on how to get your patches into RPK.
1. Patches will be dropped from the RP kernel tree in the following cases:
* Patch has been rejected upstream and maintainer has outlined a different approach to take
* Patch is showing no sign of progress upstream - either through ongoing discussion or posting of follow-up versions based on earlier reviews
* Patch doesn’t apply to a newer kernel
1. Changes to common core code will require signoff from the relevant kernel maintainer at Linaro
1. Branch maintainers will be responsible for bringing branches forward to new versions, only branches based on current -rc releases will be included.
1. Changes to shared code will require more detailed review than driver specific functionality, ideally including some indication that the upstream community is happy with this approach.
1. Members will designate an engineer who is responsible for each patch series and will address the questions/comments from the tree maintainers
1. Patches can only be accepted for HW platforms that are shared with Linaro
1. Each out-of-tree patch will be tagged (by the RPK maintainer) with one of the following keywords to allow easy accounting and tracking their progress upstream:
* `fromlist`: Patch is picked up from a public mailing list where it is being reviewed
* `fromtree`: Patch is picked up from a subsystem maintainer tree where it is already queued for merging
* `temphack`: Patch is needed temporarily until some underlying code is fixed or refactored correctly upstream
* `noup`: Patch is only needed for enabling pre-production HW or is only needed for local testing and won’t be pushed upstream. The problem will be fixed correctly upstream
* `topost`: (to post) Patch isn’t posted to the list yet but posting is imminent. These patches will only be allowed very rarely solely at the discretion of the RP kernel maintainer
1. Statistics will be published regularly on how much functionality is still out-of-tree for each platform and high-level highlights of status of upstreaming for each feature being carried out-of-tree.
## Responsibilities
@ -29,5 +23,5 @@ See [Responsibilities](#Responsibilities) on how to get your patches into RPK.
LEG members will submit their kernel topics to LEG for inclusion. These will then be integrated into a branch by the LEG kernel maintainer for inclusion into the RPK.
### Hardware enablement
Basic support for new platforms should already exist in mainline before it'll be enabled in RPK. Additional features that are still pending upstreaming may be submitted via the relevant landing team or platform maintainer for inclusion into RPK.
Basic support for new platforms should already exist in mainline before it'll be enabled in RPK. Additional features that are actively being worked on upstream may be submitted via the relevant landing team or platform maintainer for inclusion into RPK.