FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 01-23-2009, 01:38 PM
Andy Whitcroft
 
Default mainline kenel builds V1

I have been working on the mainline kernel builds action from UDS.
There are two drivers for this functionality:

1) mainline kernels at the same levels as our Ubuntu kernels. If we have
a kernel which incorporates 2.6.27.12 it is useful to offer a vanilla
2.6.27.12 for comparison against allowing us to eliminate the Ubuntu
delta as the issue, and

2) linus kernels. It is helpful to have mainline kernels to allow testing
of bleeding edge kernels.

For this discussion we are talking about officially tagged kernels,
v2.6.27.12 or v2.6.29-rc2, we are not considering -git kernels at this
time.

Following this email are two patches. The first modifies the configuration
system to simplify the build process. The second carries the build
script itself.


= Naming =

Our first major problem is how should we name the kernels produced in
this way. There are a large number of conflicting factors, we need:

1) to be able to install one or more of these kernels without affecting
the currently installed kernels;

2) to be able to clearly recognise these kernels when they are installed both
when selecting them on the boot menu and when reporting them in uname -a
(remember we do not have /proc/version_signature in mainline kernels);

3) our current build machinary expects to name the packages based on
the first three components of the kernel version number and the ABI
number, these in combination need to be unique to prevent collisions
in /lib/modules; and

4) valid package version numbers, any naming must fit into the valid
version numbers and so cannot contain '.', '_', or '-' in most parts
of the name that we can change (see 3).

Of these (1) and (3) combine to limit us to modifying the abi number,
and the contents of this must be unique to the kernel. (2) and (4)
combine such that we must encode the full version number in as near to a
human reable form as possible. To this end I am proposing we encode
this as below. Basically that we convert the version number string by
converting the number in it to be two digits, remove the '.' and '-'
symbols. For example the abi number for the following releases is as
below:

v2.6.27 020627
v2.6.27.12 02062712
v2.6.29-rc1 020629rc1

Where the commit does not have an official tag for example if we are
taking a kernel between tags say for a -gitN release
we further append the abbreviated sha1 of the actual commit. This would
not be the common case. This would appear as below:

v2.6.27.12^ 02062711ge1e04d6

Note that this is the ABI number we are modifying and so we will end up
with kernels with names as below:

v2.6.27 2.6.27-020627
v2.6.27.12 2.6.27-02062712
v2.6.29-rc1 2.6.29-020629rc1
v2.6.27.12^ 2.6.27-02062711ge1e04d6

As an example I built v2.6.27.12 for Intrepid:

mainline-build v2.6.27.12

giving me kernel .debs which look like this:

linux-image-2.6.27-02062712-generic_2.6.27-02062712_i386.deb

installing like this:
/lib/modules/2.6.27-02062712-generic
/boot/vmlinuz-2.6.27-02062712-generic
/boot/initrd.img-2.6.27-02062712-generic

and showing up in uname as below (again remember we have no
version_signature on mainline kernels):

Linux pinky 2.6.27-02062712-generic #1
SMP Fri Jan 23 12:34:01 UTC 2009 i686 GNU/Linux


= Build Script =

Following this email (patch 2) is the first version of the build script.
This is designed to be run in a special git repository. Special in the
sense that it is a virgin ubuntu-intrepid (or ubuntu-jaunty) tree with the
required mainline release added as a remote and fetched into it. That is
such that the commit you wish to build and its tags are available within
the repository. You then simply run mainline-build <commit> to generate
the binary debs required:

debian/scripts/misc/mainline-build v2.6.12

I see this being used in this manner. We would make a mainline build repo
by cloning say the each ubuntu-* tree which we care about. We could then
add a remote of upstream connected to the stable tree for that release.
This would be fetched on a regular basis from a cronjob. As new mainline
tag appear this would trigger execution of the mainline-build script
as above. The resulting binary .deb's would then be collected in a
web accessible directory for installation.

NOTE: that as things stand we need to modify the config generators to
allow us to run make oldconfig to take the default options as often
the config we are using is not 100% compatible with the new kernel.
The patch to modify this also follows this email (patch 1).


= Requirements =

We would need to find or generate a machine environment where we are
able to:

1) access mainline releases (git.kernel.org),
2) access our main ubuntu-* repositories (kernel.ubuntu.com), and
3) access to schroot environments for the supported architectures.

I believe we can split the processing between say zinc and ronne pretty
easily assuming we can transfer data between them. We need to think on
what the least we would need to ask for to make this work actually is.

Comments?

-apw

Andy Whitcroft (2):
UBUNTU: allow us to build default configs for automated builds
UBUNTU: mainline-build -- add build machinary for mainline builds

debian/rules.d/1-maintainer.mk | 10 +++
debian/scripts/misc/mainline-build | 127 ++++++++++++++++++++++++++++++++++++
debian/scripts/misc/oldconfig | 12 ++-
3 files changed, 145 insertions(+), 4 deletions(-)
create mode 100755 debian/scripts/misc/mainline-build


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 07:36 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org