Re: Single kernel package discussion.
Hi Sven,
On Sun, 15 May 2005, Sven Luther wrote:
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.
Ok, I'll summarize to make sure that I understand it correctly. On powerpc
(and possibly on mips) you start with a common kernel source, which is
then patched with subarch-specific patches to produce subarch kernel
source. Kernels for different flavours within the subarch are built using
the same subarch kernel source, but different configs. Is that correct?
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.
Well, I have slightly different ideas about it. First of all, I think that
kernel-build package is completely redundant and is not present on many
architectures. I think in the simplest possible scheme the subarch level
is not required, so that we have only arch and flavours within it. In a
unified scheme stuff is distributed over the packages as follows:
kernel-source-$(version)
Contains source, debian patches, and arch/subarch specific
patches. The latter include the unmerged patches, such as hppa
kernel patch and your powerpc subarch-specific patches. The
rationale is to keep all the source code and patches in one pile.
kernel-image-$(version)-$(abiname)-$(flavour)
Kernel image package for a particular flavour. kernel-image and
kernel-headers-* packages below are produced by the common
kernel-image package. In order to apply arch/subarch specific
patches, it will use the --added-patches mechanism of the
make-kpkg, infrastructure for it is already in place (well, I was
not counting that added patches may be flavour-specific, but this
is easy to correct).
kernel-headers-$(version)-$(abiname)
This is arch-specific headers package containing all the common
headers/configs/Makefiles, etc.
kernel-headers-$(version)-$(abiname)-$(flavour)
This is flavour-specific headers package, containing the
flavour-specific headers/configs/Makefiles, etc. This should
depend on the arch-specific kernel-headers package above, and
setup the symbolic links to the dirs in it, so that the
/usr/src/kernel-headers-$(version)-$(abiname)-$(flavour)
directory contains the complete tree, needed for building of
out-of-tree modules.
kernel-image-$(version)-$(abiname)-$(flavour)
Kernel image matching the above kernel-headers package.
In order to build the out-of-tree modules one then has to install the
kernel-headers-$(version)-$(abiname)-$(flavour), corresponding to
their kernel. This will pull in the arch-specific headers package and
provide the complete tree. Note, that
kernel-headers-$(version)-$(abiname)-$(flavour) package should provide a
symbolic link
/lib/modules/$(version)-$(abiname)-$(flavour)/build ->
/usr/src/kernel-headers-$(version)-$(abiname)-$(flavour)
the same way the kernel-build package on powerpc currently does.
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.
Right, I've completely missed this possibility, will have to look closer
at it. Regarding your proposals for discussion on other topics, I do not
have anything to say yet. I definitely plan to draft some sort of howto
for building the out-of-tree modules one we have settled the unified
packaging scheme for all arches.
Best regards,
Jurij Smakov jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
Reply to: