lkml.org 
[lkml]   [2000]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectProposal: Linux Kernel Patch Management System
Date
> Here is a proposal to improve the kernel development process.  It was
> co-written by Sebastian Kuzminsky, Linus Torvalds, Theodore Ts'o, and
> myself. We are posting the proposal here for public review and
> comment. Seb is the guy writing on the software; he's nearly done the
> initial version.

What you are actually trying to do is to implement a feature-based
software configuration management system.

> Required tags:
>
> "Version" - the base kernel version. For example, "2.4.0-test8-pre1".
> The web page will list valid version strings.

Note that this could just as well be the first item on Requires tag.

For example, each Linux kernel would need the one before it:

linux-2.2.17 requires linux-2.2.16 which requires linux-2.2.15 etc.

> "Requires" - followed by one or more kernel-patch identifiers.
> For example, "KP7555".

Rembember that the ordering of the Requires tag is quite important if
there are multiple patches modifying the same files. Currently I'm
working on a kernel which is based on linux-2.2.16 and also has the
backport of the USB code from linux-2.4.something, a patch with a
driver for a device, and yet another patch for something else. Most
of these patches are not dependent on each other really, but a few of
them touch the same files which makes things a bit complicated.

It would be very nice if the creator of the patch could give the patch
some kind of "base name", as it'll be Alexander S A Kjeldaas wrote,
it's much easier to understand what "geode-irq-fixup-12" means than
"KP3712". Maybe this should be called a "Feature" instead of
base-name, because that's what it is, the patch implements a feature.

A very nice tool to have would be an automatic patcher where I say "I
want this patch, get everything it needs" and which then performs all
the patching. Say that I'm working on an USB driver for the National
Semiconductor Geode which is currently based on the following stuff:

linux-2.2.14
usb-2.3.99-pre7-1-for-2.2.14 (requires linux-2.2.14)
wingel-usb-12 (requires usb-2.3.99-pre7-1-for-2.2.14.diff)

So if I say "I want the wingel-usb-12" version, it'll download and
patch everything in order. (Actually, the wingel-usb-12 patch might
even be empty, the only thing I'm using it for is to select which
set of features/patches I want.)

A few things to thing about here, what should happen if I upgrade the
Linux kernel to 2.2.16? I should be able to patch it with the usb
patch for 2.2.14 since the tool should be able to tell that
linux-2.2.16 is a successor of linux-2.2.14, but at the same time it
should tell me that I'm trying to do an imperfect patch (which might
result in rejects) and not allow me to do this automatically. What
I'd have to to is to apply the patch manually and create a new
usb-2.3.99-pre7-1-for-2.2.16 patch instead. This will of course force
me to create a new wingel-usb-13 patch too.

linux-2.2.16 (obsoletes linux 2.2.14-15)
wingel-usb-2.3.99-pre7-1-for-2.2.16 (requires linux-2.2.16 and
obsoletes usb-2.3.99-pre7-1-for-2.2.14)
wingel-usb-13 (requires usb-2.3.99-pre7-1-for-2.2.16 and obsoletes
wingel-usb-12)

Actually, the tools could have a few more goodies. While I've been
waiting the guy doing the usb backport has released a new version
which based on a newer 2.4 kernel and is relative to the 2.2.16
kernel, so what I'd really like is to use that patch instead. The
tools would probably have to do some interesting backtracking to
figure out that usb-2.4.0-for-2.1.16 is related to my
wingel-usb-2.3.99-for-2.2.16 through a common ancestor
usb-2.3.99-for-2.2.14.

linux-2.2.16
usb-2.4.0-test2-pre2-for-2.2.16-v3 (requires linux-2.2.16 and
obsoletes usb-2.3.99-pre7-1-for-2.2.14)
wingel-usb-14 (requires usb-2.4.0-test2-pre2-for-2.2.16-v3 and
obsoletes wingel-usb-13)

I belive that linux-2.2.17 includes the usb-2.4 backport, so if I do
that move I'll end up with:

linux-2.2.17
wingel-usb-14 (requires linux-2.2.17)

It would be nice if the tracking of the usb code doesn't disappear
when it's incorporated into the kernel, since a new backport might be
needed in the future, but I'm not sure if that is possible.

I think I've written too much again, but I've been thinking and
reading about the same thing for quite a while and just wanted to do a
brain-dump of what I've been thinking of.

Comments?

/Christer

--
"Just how much can I get away with and still go to heaven?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.131 / U:0.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site