First kernel upload for gutsy...priceless

Ben Collins ben.collins at ubuntu.com
Thu May 3 14:52:48 UTC 2007


On Thu, 2007-05-03 at 12:33 +0100, Matt Zimmerman wrote:
> On Fri, Apr 27, 2007 at 05:00:33PM -0400, Ben Collins wrote:
> > The new build system is in effect in linux-source. I've updated the wiki
> > to reflect a few things about it, but I still need to do a large bit of
> > public documentation. There's lots of comments and a few READMEs in the
> > debian/ directory. It has some great features, including a build time test
> > suite that we plan to use for module validation, among other things.
> 
> If this helps to simplify kernel maintenance and makes it easier to
> implement new functionality, I'm all for it.  I have a few questions and
> concerns, though.
> 
> First, what's the rationale for splitting linux-ubuntu-modules into a
> separate source package?  This requires an additional upload for every
> kernel ABI change, including some security updates, which is something we
> originally tried to minimize by bringing drivers in-tree.  I think we're now
> up to four (kernel, ubuntu, restricted, meta).

The rationale is that it gives us clear separation of our stock kernel
code and our third party drivers (both in maintenance and in bug
tracking).

We had talked about this quite awhile back, with Kees and Martin, and
they both agreed that one more package would not be a problem at all.

> I'm also concerned about the possiblity for users to end up without
> linux-ubuntu-modules, losing functionality.  The ipw2200 firmware, for
> example, is in this package, and without it the driver fails in mysterious
> (to a desktop user) ways.  The metapackages are convenient, but they have
> not been a panacea, and we already have occasional problems of this type
> with l-r-m.


The linux-image-generic package will depend on the matching kernel image
and ubuntu modules.

This means that it is impossible for someone to perform an upgrade from
feisty and get linux-image-2.6.22-1-generic, but not get
linux-ubuntu-modules-2.6.22-1-generic. There is nothing to cause the
kernel image to get updated without also bringing in the modules.

For them to get linux-image-2.6.22-1-generic without
linux-ubuntu-modules-2.6.22-1-generic, would mean they did not have
linux-image-generic installed, and manaually installed the kernel image.

> > Part of this new build system brings us some new and interesting
> > flavours right out of main tree: Xen and Real-Time.
> > 
> > Previously, large patchsets like this were rejected, and required to be
> > built out-of-tree. There's a million reasons we did this, but the main
> > one is that we didn't want this patch in our stock source. With the new
> > build system, however, we can have flavours which patch the stock source
> > at build time to produce a sand boxed build. So while we have Xen and
> > Real-Time kernels (-xen and -rt flavours), the main kernels are not
> > patched with this code.
> > 
> > This is a big win for us and the community. It means we can provide
> > steady updates during development cycle, and provide things like
> > linux-restricted-modules. For post release it means that security
> > updates will benefit even these targets.
> 
> What happens if the patch fails to apply, or the patched source fails to
> build?  How does it affect the build time for kernel uploads?

In order to get these patches in, I required that they be backed by our
community both in some measurable man power and in infrastucture. So
bugs on these packages, and patching issues that arise in them will be
handled by these teams (Ubuntu Studio and ubuntu-xen for example). If
issues can't be fixed, then the flavour will get disabled. Once we get
near release, we will evaluate the flavour for whether or not it will
remain for release.

Since the new build setup will decrease the over all time for the
package build (last upload did not include concurrency support to take
advantage of the SMP buildd's, but next one will), I think the time we
save there makes up for the extra time to build the extra kernels.

> > Please note that this does not mean we'll be doing a flavour for any old
> > patch that someone drops in an email and sends our way. So please, hold
> > your suspend2 requests, and similar. Even though this is easier to
> > maintain, it still means we have to maintain it. If the patch doesn't
> > apply, we gotta do something about it (especially if the team involved,
> > like ubuntu-studio and ubuntu-xen, don't keep their end of the
> > bargain :)
> > 
> > This is the last kernel upload you'll see for a few weeks. 3/4 of the
> > kernel team will be on the road next week, and the following week is UDS
> > where we'll all be drinking the night away in some spanish saloon, maybe
> > dodging bulls in our spare time.
> > 
> > So happy kerneling everyone!
> > 
> > PS: -rt and -xen did not get nvidia or fglrx builds in lrm. For -rt it
> > was because Ingo's patch changes some things so that nvidia and fglrx
> > kernel modules link to GPL-only symbols, thus making them unloadable.
> > 
> > 
> > -- 
> > Ubuntu:    http://www.ubuntu.com/
> > Linux1394: http://www.linux1394.org/
> > 
> > 
> > -- 
> > ubuntu-devel-announce mailing list
> > ubuntu-devel-announce at lists.ubuntu.com
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
> 
> -- 
>  - mdz
> 
-- 
Ubuntu:    http://www.ubuntu.com/
Linux1394: http://www.linux1394.org/





More information about the kernel-team mailing list