Single kernel package discussion.
On Sun, May 15, 2005 at 05:30:46AM +0000, Jurij Smakov wrote:
> Author: jurij-guest
> Date: 2005-05-15 05:30:44 +0000 (Sun, 15 May 2005)
> New Revision: 3113
>
> Added:
> branches/kernel-image-2.6.11/arch/i386/config.default
> Modified:
> branches/kernel-image-2.6.11/README
> branches/kernel-image-2.6.11/debian/rules
> Log:
> "Good enough to build broken i386 packages" commit.
> Everything is more or less in place, need to audit
> the build procedure for individual arches and put
> in the remaining bits and pieces.
Jurij, ....
Thanks for taking up the work to make this happen. A few comment based on my
2.4 powerpc package experience, and discussion with Thiemo over the mips
kernels.
We have to consider 3 levels, and not only two of them as you do, this is the
case for the 2.4 powerpc kernels, will be the case for the 2.6 ones nextly,
and is the case for the mips kernels, which have individual non-merged
patches.
The first level is the arch level, and we are all aware of what this means.
Notice though that at least for powerpc, but probably for sparc and others
too, the 64bit variant is not considered a different arch, in opposition to
the x86/amd64 situation.
The second level is the subarch level. Each kernel in a same subarch will have
the exact same kernel source code, so if an arch has various conflicting patch
sets (as was the case in 2.4 between the main powerpc, and the nubus/apus
patches, and is the case on mips also as i understand). Another way to
distinguish between subarches independently of patches is by saying that the
kernel-header package that is generated for them differs. In the powerpc case,
the ppc64 kernels form also a different subarch of the ppc kernels.
The third level is the flavour level, and all flavours inside a given
arch/subarch share the same source code and produce the same kernel-headers,
and eventually the same kernel-patch if it is not empty. The only difference
between them is that the .config file differes, and thus we generate different
kernel-images and kernel-build files.
There is a fourth hidden level which is for packages with indentic kernels,
but which come in different packaging, like happened for powerpc, where we had
the the main vmlinux used by yaboot, quik and bootx, but also the zImage.chrp
and zImage.prep used on the chrp and prep subarches directly. I used to
provide different packages for this in the 2.4 days, but it is a huge
duplication of packages, and not really worth it. It is recomended to hide
this level away and do the differentiation in a postinst, like the mkvmlinuz
call of the 2.6 powerpc kernels.
Any coments on the above ? I think it is sound, and it covers every existing
case, while in many cases there will be only one subarch per arch, and many
flavours. Maybe we need to rename stuff, but this has worked for the arches
which need 3 levels.
So, what of the generated packages ? We have :
source -> generate kernel-source, kernel-tree, kernel-patch and kernel-doc.
arch -> nothing.
subarch -> generates kernel-patch-<subarch> and kernel-headers-<subarch>
flavour -> generates kernel-build and kernel-image.
I think all of this is obvious, but i want to explain how
kernel-headers/kernel-build work, and get some comment since this is perhaps
the most difficult part of it, and it may not correspond to the needs of the
non-powerpc arches.
On powerpc, the kernel-headers are the one generated by make-kpkg, without
modification, and i believe simply copy the headers into the package. The main
thing i am not sure of here is if the different config options used do or not
modify the kernel-headers, but i get the feeling that they are modified on
usage, and not when the package is built. The kernel-build contain a couple
arch files (arch/ppc/Makefile, arch/ppc/kernel/asm-offsets.c|Makefile),
Module.symvers, scripts, and two include files (include/linux/autoconf.h|version.h)
and naturally the .config file used. The rest of it are symlinks to the
various files of the kernel-headers.
The kernel-build is specific to each kernel-image package, and can be used to
build third party modules (in fact it is the only use for it and the headers,
now that glibc uses its own stuff). As such, kernel-build also sets the
/lib/modules/<version>/source|build symlink (not sure which of them is the
right one) to point to the kernel-build dir (/usr/src/kernel-build-<version>),
and allow to automatically build modules even without having to set the KSRC
thingy.
The last point is of the files needed to support the different kernel
'packaging', the powerpc kernel supports mkvmlinuz by copying a couple of
object files from arch/ppc/boot into the kernel-image, as to be able to do the
last step of the zImage.chrp|prep|... construction at install time, and embedd
initrds. Other arches have similar needs, but maybe separated tools to do this
job. The work of calling them should go into the individual kernel-image.
Ok, that i believe covers all that is needed to make a single package
producing all the kernel-images and assorted files, please comment if i missed
something, i especially welcome comments of the different arch porters with
regard to their individual needs.
Next points to put under discussion are : 1) inclusion of .udeb generation (in
particular, it would make sense to push the granularity to one .udeb per
individual module, so you can load them on demand via discover or hotplug or
whatever), 2) build infrastructure on the different arches, especially the
slower arches may have trouble with nearly following kernel releases, 3)
unification with the ubuntu kernel upto a point, in order to stop doing double
work, and 4) relationship with external modules (nobody seems to care about
this yet though, since nobody replied to my post about this) and third party
patches.
Friendly,
Sven Luther
Reply to: