| 1 |
g2boojum |
1.1 |
GLEP: 26
|
| 2 |
|
|
Title: Handling kernels with portage
|
| 3 |
g2boojum |
1.2 |
Version: $Revision: 1.1 $
|
| 4 |
|
|
Last-Modified: $Date: 2004/05/03 01:48:45 $
|
| 5 |
g2boojum |
1.1 |
Author: Nathaniel McCallum <npmccallum@gentoo.org>, Joshua Campbell <warpzero@gentoo.org>
|
| 6 |
g2boojum |
1.2 |
Status: deferred
|
| 7 |
g2boojum |
1.1 |
Type: Standards Track
|
| 8 |
|
|
Content-Type: text/x-rst
|
| 9 |
|
|
Created: 2-May-2004
|
| 10 |
g2boojum |
1.2 |
Post-History: 2-May-2004, 11-Nov-2004
|
| 11 |
g2boojum |
1.1 |
|
| 12 |
|
|
Abstract
|
| 13 |
|
|
========
|
| 14 |
|
|
|
| 15 |
|
|
This GLEP proposes to create a more consistent handling of kernels and kernel building.
|
| 16 |
|
|
Currently "emerge kernel-name" only installs the sources and does not build anything.
|
| 17 |
|
|
"emerge kernel-name" should install only sources OR only a binary kernel, its modules,
|
| 18 |
|
|
and a tarballed package of kernel-headers, depending on USE flag.
|
| 19 |
|
|
|
| 20 |
g2boojum |
1.2 |
Status
|
| 21 |
|
|
======
|
| 22 |
|
|
|
| 23 |
|
|
Timed out
|
| 24 |
|
|
|
| 25 |
|
|
|
| 26 |
g2boojum |
1.1 |
Motivation
|
| 27 |
|
|
==========
|
| 28 |
|
|
|
| 29 |
|
|
Currently, the only automated kernel build proceedure that we have is genkernel. While
|
| 30 |
|
|
genkernel is a great tool, its main weakness is that it does not port well to other
|
| 31 |
|
|
arches because of the initrd and the lack of good "generic" settings for other arches.
|
| 32 |
|
|
This GLEP hopes to overcome this by abstracting the various layers of genkernel and
|
| 33 |
|
|
implementing the most common aspect (the build proceedure) into a portage eclass.
|
| 34 |
|
|
|
| 35 |
|
|
Specification
|
| 36 |
|
|
=============
|
| 37 |
|
|
|
| 38 |
|
|
There would be 3 layers to kernel building: (place of implementation)
|
| 39 |
|
|
|
| 40 |
|
|
- Stage 1 - Configuring the kernel (optional) -- external utility
|
| 41 |
|
|
- Stage 2 - Building the kernel -- in an eclass
|
| 42 |
|
|
- Stage 3 - Building the initrd (optional) -- in an ebuild
|
| 43 |
|
|
|
| 44 |
|
|
Stages 1 and 3 are optional on most arches.
|
| 45 |
|
|
|
| 46 |
|
|
Stage 1 would be achieved through a seperate utility (perhaps like the current
|
| 47 |
|
|
genkernel). This utility would help the user configure the kernel and any kernel/build
|
| 48 |
|
|
related settings. This stage is optional and would only be used if a person wanted a
|
| 49 |
|
|
customized kernel settings. One optional thought is to have this utility a part of the
|
| 50 |
|
|
base Gentoo system. That way there are less steps to make a custom kernel.
|
| 51 |
|
|
|
| 52 |
|
|
Stage 2 would be implimented through an eclass. This stage is not optional. One would
|
| 53 |
|
|
perform this step by typing "emerge kernel-name", where "kernel-name" is the name of
|
| 54 |
|
|
the kernel package you want to use (ie. "gentoo-dev"). This package would have a
|
| 55 |
|
|
"buildkernel" USE flag. If the flag was not set, it would simply download and install
|
| 56 |
|
|
sources like we do currently. However, if the "buildkernel" flag is set, portage will
|
| 57 |
|
|
perform the following steps:
|
| 58 |
|
|
|
| 59 |
|
|
1. (as a dependency) download and install a tarball of "generic" kernel config files.
|
| 60 |
|
|
2. Check to see if customized kernel config/settings have been set via Stage 1.
|
| 61 |
|
|
3. Portage will use a custom config, if available. Otherwise, a "generic" config.
|
| 62 |
|
|
4. If neither a custom config or a "generic" config is available, die (with message).
|
| 63 |
|
|
This is needed as some arches don't/can't have "generic" configs, so they will
|
| 64 |
|
|
simply be presented a message telling them to run the utility from Stage 1 (which
|
| 65 |
|
|
they obviously skipped).
|
| 66 |
|
|
5. Build the kernel and modules and install them
|
| 67 |
|
|
6. Remove unnecessary files from the sources and tarball it as "kernel-headers".
|
| 68 |
|
|
This tarball provides the appropriate files to build external modules against, like
|
| 69 |
|
|
nvidia-kernel, etc... The external modules (when built) will determine the running
|
| 70 |
|
|
kernel and unpack the appropriate tarball, to build against, then remove the files.
|
| 71 |
|
|
|
| 72 |
|
|
Stage 3 would merely be an ebuild that constructs an initrd image for either the running
|
| 73 |
|
|
kernel or, lacking a running kernel, the newest kernel installed (by version/date installed?).
|
| 74 |
|
|
Initrd's can't be used on all arches, so this ebuild can be keyword masked as appropriate.
|
| 75 |
|
|
The initrd package would also have a "bootsplash" USE flag (on x86, maybe others) that
|
| 76 |
|
|
would build in bootsplash support. Any non-default actions desired by the user can be
|
| 77 |
|
|
handled with the utility from Stage 1.
|
| 78 |
|
|
|
| 79 |
|
|
This would lead us to several case scenarios (assuming kernel-config is part of the base
|
| 80 |
|
|
system):
|
| 81 |
|
|
|
| 82 |
|
|
1. default kernel, no initrd: "emerge gentoo-kernel"
|
| 83 |
|
|
|
| 84 |
|
|
2. default kernel, initrd: "emerge aa-kernel initrd"
|
| 85 |
|
|
|
| 86 |
|
|
3. default kernel, bootsplash initrd: "USE=bootsplash emerge mm-kernel initrd"
|
| 87 |
|
|
|
| 88 |
|
|
4. non-default kernel, no initrd: "kernel-config gentoo-dev-kernel"
|
| 89 |
|
|
"emerge gentoo-dev-kernel"
|
| 90 |
|
|
|
| 91 |
|
|
5. non-default kernel, initrd: "kernel-config alpha-kernel"
|
| 92 |
|
|
"emerge alpha-kernel initrd"
|
| 93 |
|
|
|
| 94 |
|
|
6. JUST sources, no binary "USE=-buildkernel emerge grsec-kernel"
|
| 95 |
|
|
|
| 96 |
|
|
Rationale
|
| 97 |
|
|
=========
|
| 98 |
|
|
|
| 99 |
|
|
There are many advantages gained by this method:
|
| 100 |
|
|
|
| 101 |
|
|
1. Full arch support (GentooInstaller really could use this)
|
| 102 |
|
|
2. More consistent with the rest of portage (installs binaries by building from source)
|
| 103 |
|
|
3. Better user experience
|
| 104 |
|
|
4. More flexability (genkernel forces building of initrd on x86)
|
| 105 |
|
|
5. Don't have to store full kernel sources (each source tree is ~200MB unpacked)
|
| 106 |
|
|
6. Creates the ability to make binary kernel packages for fast installs (think GRP kernel)
|
| 107 |
|
|
7. A seperate package for "generic" kernel config files gives us better version tracking
|
| 108 |
|
|
|
| 109 |
|
|
The major problem is, however, that we currently have two different build systems,
|
| 110 |
|
|
portage and genkernel. Having competing build systems is not a GoodThing TM. Therefore,
|
| 111 |
|
|
we can either make portage build kernels or we can make genkernel build everything else.
|
| 112 |
|
|
|
| 113 |
|
|
Backwards Compatibility
|
| 114 |
|
|
=======================
|
| 115 |
|
|
|
| 116 |
|
|
If you want to emerge kernel sources the old way, just do: USE="-buildkernel" emerge kernel-name
|
| 117 |
|
|
|
| 118 |
|
|
Perhaps we could also name the new kernel-config program (from Stage 1) "genkernel" so that users
|
| 119 |
|
|
can have a seemless transition.
|
| 120 |
|
|
|
| 121 |
|
|
Reference Implementation
|
| 122 |
|
|
========================
|
| 123 |
|
|
|
| 124 |
|
|
not yet ..
|
| 125 |
|
|
|
| 126 |
|
|
Copyright
|
| 127 |
|
|
=========
|
| 128 |
|
|
|
| 129 |
|
|
This document has been placed in the public domain.
|
Parent Directory
| 
Revision Log