Contents of /xml/htdocs/proj/en/glep/glep-0026.txt

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.2 - (hide annotations) (download)
Thu Nov 11 21:32:21 2004 UTC (13 years, 7 months ago) by g2boojum
Branch: MAIN
Changes since 1.1: +10 -4 lines
File MIME type: text/plain

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     ========
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.
20 g2boojum 1.2 Status
21     ======
23     Timed out
26 g2boojum 1.1 Motivation
27     ==========
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.
35     Specification
36     =============
38     There would be 3 layers to kernel building: (place of implementation)
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
44     Stages 1 and 3 are optional on most arches.
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.
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:
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.
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.
79     This would lead us to several case scenarios (assuming kernel-config is part of the base
80     system):
82     1. default kernel, no initrd: "emerge gentoo-kernel"
84     2. default kernel, initrd: "emerge aa-kernel initrd"
86     3. default kernel, bootsplash initrd: "USE=bootsplash emerge mm-kernel initrd"
88     4. non-default kernel, no initrd: "kernel-config gentoo-dev-kernel"
89     "emerge gentoo-dev-kernel"
91     5. non-default kernel, initrd: "kernel-config alpha-kernel"
92     "emerge alpha-kernel initrd"
94     6. JUST sources, no binary "USE=-buildkernel emerge grsec-kernel"
96     Rationale
97     =========
99     There are many advantages gained by this method:
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
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.
113     Backwards Compatibility
114     =======================
116     If you want to emerge kernel sources the old way, just do: USE="-buildkernel" emerge kernel-name
118     Perhaps we could also name the new kernel-config program (from Stage 1) "genkernel" so that users
119     can have a seemless transition.
121     Reference Implementation
122     ========================
124     not yet ..
126     Copyright
127     =========
129     This document has been placed in the public domain.

  ViewVC Help
Powered by ViewVC 1.1.20