diff options
| author | Mcgrof <anonymous.contributor@example.org> | 2014-11-17 18:19:47 +0000 |
|---|---|---|
| committer | Konstantin Ryabitsev <konstantin@linuxfoundation.org> | 2024-10-04 15:47:32 -0400 |
| commit | 4f7e55e1993abc48169c36d8ac1f2e9ab6a881cf (patch) | |
| tree | d5ff33b724e38528f1ca05b32670cb79b1ad88cb | |
| parent | 2cc69aa6158c71373174c4b915e4e3e8348de848 (diff) | |
| download | backports-4f7e55e1993abc48169c36d8ac1f2e9ab6a881cf.tar.gz | |
Kernel integration completed
| -rw-r--r-- | wiki/Documentation_backports_hacking_todo.mediawiki | 18 |
1 files changed, 0 insertions, 18 deletions
diff --git a/wiki/Documentation_backports_hacking_todo.mediawiki b/wiki/Documentation_backports_hacking_todo.mediawiki index 46238ac..35ef69d 100644 --- a/wiki/Documentation_backports_hacking_todo.mediawiki +++ b/wiki/Documentation_backports_hacking_todo.mediawiki @@ -16,24 +16,6 @@ We should review how the upstream ''make localmodconfig'' currently works and im 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. - -This likely will require a separate script other than gentree.py, perhaps mergetree.py. - -= Motivation = - -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. - -== Who's working on this? == - -Available for anyone interested. - = 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: |