206 lines
7.7 KiB
Plaintext
206 lines
7.7 KiB
Plaintext
Migrating to the common kernel-image package
|
|
--------------------------------------------
|
|
Files for architecture <arch> should be placed into arch/<arch>.
|
|
Minimally, this directory should contain a control.in, config.default
|
|
and at least one flavour configuration file config.<flavour>. It can
|
|
optionally contain config.common, Makefile.inc and multiple flavour
|
|
configuration files. For arches with subarches the subdirectory
|
|
arch/<arch>/<subarch> with the same file structure must be created
|
|
for each subarch.
|
|
|
|
Support for arch/subarch-specific patches
|
|
-----------------------------------------
|
|
Patches specific to a particular architecture or subarchitecture and
|
|
not included into the debian patch set should be placed in the
|
|
debian/patches-arch subdirectory. Patch must be named <arch>.diff or
|
|
<subarch>.diff. If such patch is present, it will be automatically
|
|
applied during the unpacking of the build tree for a particular
|
|
(sub)architecture. Patches present in the debian/patches-arch will also
|
|
be included in the kernel-patch-debian package, suitable for building
|
|
kernels with make-kpkg.
|
|
|
|
Config files
|
|
------------
|
|
Configuration files are constructed dynamically by concatenating a number
|
|
of config files as described below. Any of the files, except the .default
|
|
and lowest-level .<flavour> files, may be missing.
|
|
|
|
For architecture without subarches:
|
|
|
|
Configuration file for kernel-image:
|
|
|
|
arch/config.common
|
|
arch/<arch>/config.common
|
|
arch/<arch>/config.<flavour>
|
|
|
|
Configuration file for kernel-headers:
|
|
|
|
arch/<arch>/config.default
|
|
|
|
For architecture with subarches:
|
|
|
|
arch/config.common
|
|
arch/<arch>/config.common
|
|
arch/<arch>/<subarch>/config.common
|
|
arch/<arch>/<subarch>/config.<flavour>
|
|
|
|
Configuration file for kernel-headers:
|
|
|
|
arch/<arch>/<subarch>/config.default
|
|
|
|
It is possible to avoid the inclusion of the arch-independent
|
|
config file (handy for the transitional period) by setting the
|
|
include_common_config variable to 'no' in Makefile.inc.
|
|
|
|
Control file
|
|
------------
|
|
The master control file debian/control must be generated before
|
|
the package is uploaded. debian/rules contains the debian/control
|
|
target, which generates the control file by concatenating the
|
|
common templates for it and substituting the variables:
|
|
|
|
@version@ Upstream kernel version, for example 2.6.11.
|
|
@major@ The major version, for example 2.6
|
|
@ltver@ linux-tree version, a single digit.
|
|
@srcver@ Source version, extracted from the changelog.
|
|
This is normally @version@-@ltver@.
|
|
@lt_depends@ The Depends field for the linux-tree package.
|
|
@lt_provides@ The Provides field for the linux-tree package.
|
|
@abiname@ Current abiname, a single digit.
|
|
|
|
For each kernel image build the control.source.in template from
|
|
templates directory is concatenated with the control.in file from the
|
|
arch/<arch> or arch/<arch>/<subarch> directory, and the following
|
|
variables are substituted: @version@, @ltver@, @major@, @abiname@.
|
|
A arch/subarch-specific control.in file should contain only entries
|
|
for binary linux-image-$(version)-$(abiname)-$(flavour) and
|
|
flavour-specific linux-headers-$(version)-$(abiname)-$(flavour)
|
|
packages. linux-headers-$(version)-$(abiname) package entry is
|
|
included automatically.
|
|
|
|
After variable substitution the resulting files are formatted to
|
|
ensure that the only blank lines are the ones separating the
|
|
entries (i.e. before the next Package: line).
|
|
|
|
Makefile.inc
|
|
------------
|
|
Each architecture subdirectory in arch may contain a Makefile.inc
|
|
file, which is included by debian/rules after definining all the
|
|
variables. It may be used to override the standard variables on
|
|
per-architecture basis and other evil things. So far the valid uses of
|
|
this file include the setting of the following variables:
|
|
|
|
include_common_config
|
|
|
|
Setting it to 'no' (without quotes) will prevent the common kernel
|
|
config from being included for this particular architecture.
|
|
Typical usage:
|
|
|
|
include_common_config := no
|
|
|
|
headers_dirs
|
|
|
|
This variable is substituted into the headers-install script,
|
|
controlling which asm-* directories are included into the
|
|
kernel-headers package. By default it is set to karch (see
|
|
above). See header-install.in file for detail. Typical usage:
|
|
|
|
headers_dirs := sparc | sparc64
|
|
|
|
headers_extra
|
|
|
|
This variable is substituted into the headers-install script,
|
|
and may be used to specify extra files, which a particular
|
|
architecture would like to include in the kernel-headers package.
|
|
Files should be specified with a full path relative to the
|
|
top-level kernel directory, unquoted and separated by spaces.
|
|
Note that you normally do not need to specify the files
|
|
arch/$(karch)/kernel/asm-offsets.s, they are going to be included
|
|
automatically.
|
|
|
|
headers_subarch
|
|
|
|
The subarch to pass to the --subarch option for the make-kpkg
|
|
call to build the kernel-headers. Typical usage:
|
|
|
|
headers_subarch := sparc64
|
|
|
|
build_subarch
|
|
|
|
Setting this variable to non-empty value will cause an option
|
|
--subarch $(build_subarch) added to 'build' and 'kernel-image'
|
|
make-kpkg calls. If a substring @flavour@ is present in the
|
|
definition of this variable, it will be expanded to the current
|
|
flavour during build time. In general, if you wish to add subarch
|
|
support for your architecture, you should contact kernel-package
|
|
maintainer to ensure that the flavour name correctly maps onto a
|
|
kernel subarch name. Typical usage:
|
|
|
|
build_subarch := pmac
|
|
|
|
or
|
|
|
|
build_subarch := @flavour@
|
|
|
|
build_makeflags
|
|
|
|
This variable may contain the make flags settings for the
|
|
make-kpkg invocation in the 'build' target. Currently it is
|
|
only used by amd64, where it should be set to something like
|
|
|
|
build_makeflags := 'CC=amd64-linux-gcc V=1'
|
|
|
|
The value of the variable must be properly quoted.
|
|
|
|
initrd_modules
|
|
|
|
This variable may contain a space-separated list of modules
|
|
which should be hard-linked into the /lib/modules/<version>/initrd
|
|
directory, so that they will be included by mkinitrd. Full
|
|
pathname relative to the /lib/modules/<version> directory should
|
|
be give, no quoting is necessary. Typical usage:
|
|
|
|
initrd_modules := kernel/drivers/video/vesafb.ko kernel/security/capability.ko
|
|
|
|
image_postproc
|
|
|
|
A command to be run after the kernel image is built. As far as I know,
|
|
it only required on sparc for stripping of the kernel which is too big
|
|
to be booted otherwise. Typical use is too ugly to be presented here.
|
|
|
|
image_prefix_flavours
|
|
image_prefix
|
|
|
|
These variables allow to prepend the 'make-kpkg kernel_image' call with
|
|
an arbitrary prefix for selected flavours. Some architectures have a
|
|
32- and 64-bit versions. If kernels are built on the 64-bit hardware, then
|
|
building a 32-bit kernel usually requires using a wrapper which sets the
|
|
correct execution domain (such as sparc32 or linux32). If the variable
|
|
image_prefix_flavours is non-empty and contains a space-separated list
|
|
if flavours, then make-kpkg invocation to create a kernel_image target
|
|
will be prepended with contents of the image_prefix variable. Typical
|
|
usage:
|
|
|
|
image_prefix_flavours := sparc32 sparc32-smp
|
|
image_prefix := sparc32
|
|
|
|
default_config
|
|
|
|
This variable controls which kernel config file will be used as a
|
|
"default" config file, used when building the kernel-headers package.
|
|
It does not really matter which file is used, see the message at
|
|
|
|
http://lists.debian.org/debian-kernel/2004/08/msg01460.html
|
|
|
|
The following algorithm will be used to determine the default kernel
|
|
config file:
|
|
|
|
* If the default_config variable is defined, use config.$(default_config).
|
|
* If it is not defined and config.default exists, use that.
|
|
* If neither default_config is defined not config.default exists, pick
|
|
the first flavour from the flavour list and use its config.
|
|
|
|
Typical usage:
|
|
|
|
default_config := 386
|