Formal request for review: [Sam Hartman <hartmans@debian.org>] Referring what kernel-images to build to the technical committee?
Hi. I posted the following message to debian-devel last night and
have received agreement with the summary and apparently (it was not
explicitly stated) with the committee as a forum from Craig and
Herbert. Thus I'd like to ask you to look at this issue. There has
been some other discussion in the thread that the following message
starts and others have brought up some issues I did not cover in my
summary. I recommend reading this discussion.
If there are any administrative hoops I need to jump through please
let me know.
------- Start of forwarded message -------
Resent-Date: Wed, 25 Apr 2001 20:30:46 -0400 (EDT)
Date: Wed, 25 Apr 2001 20:30:31 -0400 (EDT)
Message-Id: <200104260030.UAA09673@sweet-transvestite.mit.edu>
To: debian-devel@lists.debian.org
CC: kernel-package@packages.debian.org,
alsa-source@packages.debian.org (module package maintainers),
pcmcia-source@packages.debian.org,
openafs-modules-source@packages.debian.org,
herbert@debian.org (kernel-image-i386 maintainer),
cas@debian.org (concerned about package size)
Subject: Referring what kernel-images to build to the technical committee?
Reply-to: debian-devel@lists.debian.org
From: Sam Hartman <hartmans@debian.org>
Resent-Message-ID: <ygTBDC.A.QhC.qw256@murphy>
Resent-From: debian-devel@lists.debian.org
Resent-Sender: debian-devel-request@lists.debian.org
[cc list is an attempt at stakeholders for this issue. If I missed
people, I'm sorry. If I annoyed people by ccing them even though they
read the list, well I'm sorry too, but there are a fair number of
people who tend to want to be explicitly cc'd when an issue pertains
to them.]
Summary: Herbert has started building 8 different flavors of
kernel-image for i386. These flavors correspond to CPU type; for
example there is an appropriate kernel for people with 386 machines to
run and an appropriate kernel for people with Athlon machines to run.
Several concerns have been brought up on debian-devel, and while I
believe that discussion has identified the tradeoffs involved, I do
not believe we have reached consensus on a direction to follow.
While Herbert is the maintainer of the kernel image for i386,I believe
the implications of this issue extend far beyond his packages and thus
this is an issue where the interests of different developers may come
into conflict. Herbert's changes affect those who maintain module
packages like ALSA, PCMCIA, I2C and Openafs. OSome have claimed these
decisions affect the installation by CDs by taking up a significant
chunk of a CD. Concerns were raised about the bandwith and archive
space implications.
I believe that since debian-devel doesn't seem to be able to come to
consensus on this issue, we should refer the issue to a smaller group
than will fairly consider all the tradeoffs involved and come up with
a global direction for the project on this issue. One concern I have
with Herbert's decision is that the i386 architecture is taking what
appears to be a different direction than other architectures. I'd
rather have a global direction than have each architecture go off and
do their own thing. Naturally, the tradeoffs may affect different
architcetures differently, so we may end up with a different set of
kernel images for each architecture, but the relative weights of the
tradeoffs and our overall goals could be decided globally. I propose
the technical committee as an appropriate form to decide on this
issue, but I am open to other fora.
I'd like to summarize my understanding of the tradeoffs that we have
identified in the debian-devel discussion so that if we do turn this
issue over to the committee, they will know what concerns we have
already identified. Please add to the following list if I have missed
something. Note that I'm not trying to weight the tradeoffs here; I'm
trying to be fairly objective. Comments of the form "That's not
important," are not appropriate at this time. cThe goal is to
identify the issues and let whatever group we send this to evaluate
the weights of the issues. Presumably such a group would ask for
public comment on the weightings if they would find that comment
useful.
performance: By having images optimized for each processor on i386
users should see better performance. I don't believe performance
numbers were quantified in the discussion but quantifying performance
is probably important to evaluating this tradeoff.
Encouraging stock kernel use: By having appropriate stock kernels
that meet people's needs we may encourage users to use the kernels.
This provides better/more consistent testing of our configurationas
well as easier upgrade. Herbert indicated that previosly he did not
even use his own kernel image packages because they were not
optmized. This should be considered separately from performance,
because even if there is not a significant performance win, if many
more users would use the stock kernel, the advantages of doing so
might justify the change. That is, the perception of whether
optimized kernels are needed influences whether people use them and
the value of this perception may be differently weighted than the
actual reality of the performance.
Should build custom: Some argumed that users should build a custom
kernel and the distribution was doing them a disservice by trying to
provide kernels that met their needs.
Archive Size: The more kernel images we have, the more space it takes
up in the archive.
CD Size: Craig (I believe) claimed that the new kernel images take up
a significant fraction of a CD. If the number of CDs a typical users
actually has to look at gets too big, then Debian will be an
inconvenient distribution. It's all fine that have lots of CDs with
optional software on them that you don't need, but if you will need a
CD of kernels as well as a base CD, (or if the base CD overflows
because of kernels), then that could suck. People already complain we
need too many floppies to boot; they would probably be more upset if
you need more than 1 CD in typical cases.
Bandwith: So, moving these kernel images around takes up network
resources. Consider resources used to upload the image, resources
used to mirror the images resources used to download the images. I
don't actually think resources used to download the images changes
much, but we should evaluate all network resources.
Module Multiplication: Debian has module packages for things not in
the kernel or with implementations not in the kernel like PCMCIA and
ALSA. Herbert claims that module maintainers will have to build a
version of the modules for each kernel image he produces. For most of
us that currently multiplies the number of module packages we need to
build by 8. For various reasons, most module maintainers seem to want
to get kernel sources rather than kernel headers (some of these
reasons discussed below, some not directly related to this message).
It's somewhat difficult to get kernel sources and appropriate config
files in an automated manner especially for non-i386 architectures, so
building module packages is labor intensive. Multiplying work by 8 is
kind of frustrating.
Module size: When you multiply the number of module packages you also
moltiply their size. Even if the base size of kernel images is not
problematic, when you miltiply in modules size it may be significant.
Module Network: Again, you are using more bandwith. Feel free to
fold all the module multiplication into one tradeoff if it works
better.
Kernel headers: Herbert is currently building a kernel headers package
for each flavor. There are two problems with this. First, a
technical issue in that most of the information in kernel headers is
common. This could be solved as a SMOP. The second problem is that
other architectures seem to build only one set of kernel headers per
version, for the use of glibc. I assue they believe modules will use
kernel sources. However, Herbert wants module package maintaires to
use kernel headers. We should develop a consistent policy on what we
do about kernel-headers for modules. Either kernel-headers are only
for libc, in which case we bould one per version, or they are for both
libc and modules in which we build one perf flavor.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
------- End of forwarded message -------
Reply to: