This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] mkpatches: against ref-linux or pristine? (Was: Error compil

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] mkpatches: against ref-linux or pristine? (Was: Error compiling with CONFIG_PROFILING (xenoprof))
From: "Michael Paesold" <mpaesold@xxxxxx>
Date: Mon, 10 Apr 2006 15:02:54 +0200
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 10 Apr 2006 06:03:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <00a701c65c83$8cb26310$d801a8c0@zaphod><65e385dda31af24104770ee1e2244232@xxxxxxxxxxxx><00e701c65c91$e69a8f20$d801a8c0@zaphod> <7c24dec9d3c0a25c92442001bd623b45@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Keir Fraser wrote:
On 10 Apr 2006, at 12:28, Michael Paesold wrote:

"make mkpatches" creates diffs between vanilla+patches/linux-2.6.16 and xenified+patches/linux-2.6.16).

I would have thought it would make more sense for it to diff against vanilla/linux-2.6.16 (i.e., the pristine tree rather than the ref tree). Most people are going to want an all-in-one patch to apply to a vanilla kernel tree.

You are right, I also see no real value in having one xen patch + several extra patches to apply. It rather makes the process of patching more complicated. Although rpm helps me with the patching, I still have to manually review changes in patches/ everytime I rebase our own RPMs... resulting in this very thread. :-)

Does anyone see a use-case for not creating an all-in-one patch? On a second thought, a separate "make mkpatch" (or a more explicit target name) could provide an all-in-one patch without introducing transitioning problems for users of mkpatches.

Should I create a patch to implement that? (Seems rather trivial and suitable for my limited Makefile fu.)

Best Regards,
Michael Paesold

Xen-devel mailing list