[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |