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


Re: [Xen-devel] Re: [PATCH] Xen watchdog driver

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] Xen watchdog driver
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 06 Oct 2010 09:11:16 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Wed, 06 Oct 2010 09:12:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1286183752.23155.2061.camel@xxxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4CA4B4420200007800019CAB@xxxxxxxxxxxxxxxxxx> <4CA4B7F2.7060606@xxxxxxxx> <4CA5A2280200007800019E79@xxxxxxxxxxxxxxxxxx> <1286183752.23155.2061.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100921 Fedora/3.1.4-1.fc13 Lightning/1.0b3pre Thunderbird/3.1.4
 On 10/04/2010 02:15 AM, Ian Campbell wrote:
> I think we all need to start trying to move from the mindset that
> xen.git is the only target of our development efforts and instead work
> much more directly/closely with Linux upstream, in particular with
> subsystem maintainers of other areas touched by our patches.
> Many Xen patches differ from the norm in that they are cross-subsystem
> (e.g. they implement Xen functionality in the context of some other
> subsystem such as networking, block, watchdog subsystems) rather than
> being obviously single subsystem with the more normal linear progression
> through driver maintainer to subsystem maintainers to Linus etc.
> I think it should be the responsibility of the patch contributor to get
> review and thence an Acked-by from both/all subsystem maintainers (IOW
> both Jeremy and the other subsystem's maintainers), regardless of which
> tree the patch eventually gets committed to.
> For cases where there is no impediment to sending stuff directly
> upstream pushing stuff only towards xen.git works against the goal of
> having first class Xen support in the upstream kernel. Even in cases
> where a patch depends on something which is currently only in xen.git I
> think taking it to the relevant subsystem and getting an
> in-principle-Acked-by makes sense in many cases and will help with the
> eventual upstreaming. 
> I could even go so far as to argue that in many cases (especially for
> domU stuff) the primary subsystem of interest for a patch is not Xen but
> the other one and that only core Xen stuff really needs to go through
> xen.git. In other words in most cases the main target of upstreaming
> should be the maintainer of the relevant other subsystem, of course with
> Jeremy's and/or other Xen community members' Reviewed/Acked/Tested-by.
> This sort of model has already worked well for Stefano's pvhvm drivers
> and is looking good for Konrad's swiotlb/pcifront stuff too. Although
> the above is really intended as a more general comment on our
> development practices I do think a watchdog driver is another good
> example of a patch which could go via the watchdog subsystem maintainer
> rather than xen.git.

Yes, exactly so.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>