(Difference between revisions)
|
|
| Line 12: |
Line 12: |
| | # To protect the reputation of MeeGo, the owner of the adaptation kernel must ensure that security issues get fixed for the life time that the adaptation kernel is in use/supported (a minimum of 12 months after the MeeGo release) | | # To protect the reputation of MeeGo, the owner of the adaptation kernel must ensure that security issues get fixed for the life time that the adaptation kernel is in use/supported (a minimum of 12 months after the MeeGo release) |
| | # The adaption kernels must follow the same release process/timing as the rest of MeeGo; e.g. the same feature freeze, code complete dates etc etc. | | # The adaption kernels must follow the same release process/timing as the rest of MeeGo; e.g. the same feature freeze, code complete dates etc etc. |
| - | # For MeeGo compliance and consistency, all adaptation kernels must be within two kernel releases of the reference kernel. To meet the compliance objectives, MeeGo middleware and compliant applications are not allowed to require functionality that is not part of the API/ABI of the upstream "minus two" kernel. | + | # For MeeGo compliance and consistency, maintainers of "adaptation kernels" are required to backport any and all relevant userspace visible kernel features from the reference kernel so that applications and middleware that runs on the reference kernel can assume reasonable feature and functionality parity. |
| | # The MeeGo compliance profile will have a set of kernel configuration options that are required to be set, in order to provide a consistent ABI and consistent functionality to the application stack | | # The MeeGo compliance profile will have a set of kernel configuration options that are required to be set, in order to provide a consistent ABI and consistent functionality to the application stack |
Revision as of 19:37, 15 December 2010
Proposal for the TSG to ratify the new MeeGo kernel policy - on agenda for Dec 15, 2010.
In the recent weeks it has become clear that we have several hardware vendors/devices that are relevant for MeeGo, but for which the supporting code is not upstream yet.
While the code is slowly making its way into the upstream kernel, each of these devices has an enormous (hundreds) list of patches, that not only make the MeeGo kernel unmanageable, they also conflict with the patch series of other vendors that are in the same position.
For this reason, we are proposing a change in how MeeGo (including compliance) handles the kernel for such platforms:
- MeeGo will ship with one 'reference kernel', that will have one shared codebase between all the devices it supports (with different configuration files). This kernel will be close to the upstream kernel with very few patches applied to it, and the version will be chosen by the architecture team such that the kernel is relatively recent, while still allowing for a reasonable stabilization period before a MeeGo release ships.
- For a platform to be part of this `reference kernel', the supporting adaptation code (drivers/etc) needs to already be in the upstream kernel for the version that the reference kernel uses. It's assumed that such a platform will only need a low number of small patches to fix the occasional bug.
- For platforms that cannot or do not want to use the reference kernel, a separate RPM package will be created in one of the MeeGo OBS instances. This package will be named kernel-adaptation-<platform name> to clearly mark it as separate from the reference kernel. The hardware vendor/platform enabling team for the platform will have complete ownership and responsibility for this separate kernel (adaptation kernel) package. At least one maintainer is identified by name who will be the contact for all bugs and integration issues.
- Having a separate "adaptation kernel" does not absolve the kernel owner from the requirement that all the code must go into the upstream kernel in a reasonable timeframe
- To protect the reputation of MeeGo, the owner of the adaptation kernel must ensure that security issues get fixed for the life time that the adaptation kernel is in use/supported (a minimum of 12 months after the MeeGo release)
- The adaption kernels must follow the same release process/timing as the rest of MeeGo; e.g. the same feature freeze, code complete dates etc etc.
- For MeeGo compliance and consistency, maintainers of "adaptation kernels" are required to backport any and all relevant userspace visible kernel features from the reference kernel so that applications and middleware that runs on the reference kernel can assume reasonable feature and functionality parity.
- The MeeGo compliance profile will have a set of kernel configuration options that are required to be set, in order to provide a consistent ABI and consistent functionality to the application stack