[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Citrix PV Bus device



> -----Original Message-----
> From: Ian Campbell
> Sent: 02 July 2013 14:43
> To: Paul Durrant
> Cc: Tim (Xen.org); qemu-devel@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH] Citrix PV Bus device
> 
> On Tue, 2013-07-02 at 13:51 +0100, Paul Durrant wrote:
> > Yes, that makes sense *but* I would still like to avoid carrying a
> > private patch to QEMU (and potentially have to keep rebasing it),
> 
> It's small and pretty self contained I think.
>

It still has external interfaces, to tracing, QOM, etc that may change.
 
> FWIW I don't think QEMU should be the registry of these device IDs. Can
> you create a file somewhere in the Xen source base to serve as the
> registry, probably somewhere under xen/include/public.

I'll look at how best to do this.

> 
> We should probably have some sort of scheme. How about we declare the
> topmost available bit of the device id to be the "vendor specific" bit?
> We could split the dev id into N-bits of "vendor" and M-bits of device,
> or add a "locally administered" bit, but that might be overkill?
> 
> >  and any VM provider (with a suitable version of QEMU on their host)
> > can then enable the device should they wish.
> 
> I imagine they would be worried about you pushing new drivers which
> depend on new XenServer features. So unless they also intend to
> implement (and track) your version compatibility xenstore keys (or
> whatever mechanism) I'm not sure why they would want to do such a thing.

We already have people interested in doing this and we would look to QA in 
those non-XenServer environments, to ensure compatibility.

> Or are you proposing to maintain forward and backward compatibility?
> i.e. based on feature flags and negotiation with backends rather than
> versioned platform devices or other XenServer specific mechanisms?
> 

In general yes. Modifying the platform device revision is a mechanism of last 
resort (because of the inconvenience it causes) but one that we may still need 
at some point.

> In any case they could also apply the patch. If it turns out that lots
> of people are doing so then maybe that is the time to consider it for
> upstream.
> 

We already have interested parties and the device not being available upstream 
is an inconvenience.

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.