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.026 / U:30.240 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site