Re: [PATCH v5 2/5] libxl: add query function for backend support by device model

[Wei Liu <wei.liu2@citrix.com>]

On Wed, Mar 30, 2016 at 03:10:45PM +0100, George Dunlap wrote:
> On 30/03/16 14:53, Wei Liu wrote:
> > On Wed, Mar 30, 2016 at 02:05:55PM +0200, Juergen Gross wrote:
> >> Add a function to query whether the device model is supporting a
> >> specific backend type. The device model is writing the supported
> >> backend types to Xenstore on startup. The new query function checks
> >> for the appropriate entry to be present.
> >>
> >> As not all versions of qemu are capable to indicate support of
> >> specific backends the query function is to be called with an indicator
> >> whether the default return value should be "supported" (in case qemu
> >> doesn't know set any support information) or "not supported".
> >>
> >> Signed-off-by: Juergen Gross <jgross@suse.com>
> > 
> > The code itself looks straightforward enough.
> > 
> > But note that this is a new protocol that needs to be supported
> > essentially forever. I've CC QEMU maintainers for their input.
> 
> FWIW, libxl only needs to support this forever if qemu ever actually
> provides it.  If no version of qemu ever ships with this check, then we
> can't break anything by removing it.
> 

That's true. But the code is actually not very relevant, I think the
protocol shall be written down somewhere in a canonical document --
that's something that we can't easily revert -- unless we don't document
it, then I'm not sure what state should this feature be in or how do we
advertise it in our release note.

Wei.

> This is what I was saying in my other comment -- we could just check
> this in, and back out the whole series if the qemu side gets NACK'ed.
> Even if we release with this, there's no real harm done, as the qusb
> code will simply never be activated.
> 
> > This also means even if we get this in for 4.7 we can't essentially
> > benefit from it until this protocol is implemented in upstream QEMU. At
> > this point I don't think I would take this particular patch for 4.7.
> 
> qemu has a faster release cycle than us, right?  If we have support in
> principle for this approach, people who want qusb support can always use
> a newer qemu release.
> 
> OTOH, if we check this in then the qemu folks can either take this exact
> approach, or something completely incompatible -- they can't make minor
> modifications.
> 
>  -George

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