| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH] Xen watchdog driver
On Fri, 2010-10-01 at 07:56 +0100, Jan Beulich wrote:
> >>> On 30.09.10 at 18:16, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> > On 09/30/2010 07:01 AM, Jan Beulich wrote:
> >> While the hypervisor change adding SCHEDOP_watchdog support included a
> >> daemon to make use of the new functionality, having a kernel driver
> >> for /dev/watchdog so that user space code doesn't need to distinguish
> >> non-Xen and Xen seems to be preferable.
> >
> > Looks good. Are you going to submit this upstream?
>
> By sending it to you I thought I did.
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.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home