Migrating to the common kernel-image package
-------------------------------------------- 
Files for architecture <arch> should be placed into arch/<arch>. This
directory normally contains a common config file for this architecture
('config'), flavour-specific config files, Makefile.inc file,
controlling the build for this arch, and the defines file, containing
the machine descriptions for various flavours.  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. 

For architecture without subarches:

  Configuration file for kernel-image:

  arch/config
  arch/<arch>/config 
  arch/<arch>/config.<flavour>
  
For architecture with subarches:

  arch/config
  arch/<arch>/config
  arch/<arch>/<subarch>/config
  arch/<arch>/<subarch>/config.<flavour>

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 invoking the 
debian/bin/gencontrol.py script, which combines the templates from
the templates directory and arch/subarch specific defines file to
produce the debian/control file. Note that this target is intentionally
made to fail with a non-zero exit code to make sure that it is never
run during an automatic build. The following variables are substituted
into the templates:

@version@      Upstream kernel version, for example 2.6.11.
@major@        The major version, for example 2.6
@arch@         The Debian arch name, such as powerpc or i386.
@subarch@      The subarch - only used by powerpc right now.
@flavour@      The build flavour, such as 686 or k7-smp.
@class@        The CPU/architecture class; displayed in synopsis.  It should
               be fairly short, as the synopsis is supposed to be <80 chars.
               It should be in the form "foo class", and will show up in the
	       description as "foo class machines".
@longclass@    The CPU/architecture class; displayed in the extended
               description.  The same rules apply as in @class@.  If
	       this is unset, it will default to @class@.
@desc@         (Potentially) multi-line verbiage that's appended to
               -image descriptions.
@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.
@allheaders@   Given the arch, a list of all the linux-headers packages for the
               arch - used for kernel-headers-x.y.z-n-arch.

Normally, the arch-specific contents should be controlled by
adjusting the corresponding defines file.

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:

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_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

extra_postinstall_command

  This variable, if defined, is executed at the end of the
  post-install script, which is used by kernel-package to add or
  modify the files going into the kernel image package.

  It can use these variables (but see templates/post-install.in for
  details): $(subarch), $(flavour), $(version) and $(abiname). Since
  Makefile.inc is a Makefile, the leading $ need to be escaped as
  double $$.