Re: [PATCH v7] sndif: add ABI for Para-virtual sound

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-03-17 at 13:05 +0000, Lars Kurth wrote:
> > On 17 Mar 2015, at 11:40, Ian Campbell <ian.campbell@citrix.com> wrote:
> > 
> > On Thu, 2015-03-12 at 18:14 +0000, Lars Kurth wrote:
> >> Hi,I nearly missed this. Please make sure you forward stuff and change
> >> the headline if you want me to look into things. Otherwise I may miss
> >> it.
> > 
> > Sure, I'll try and remember.
> > 
> > FYI before Ian J went away he mentioned that he had raised some
> > questions/issues (either on this or a previous version) which had not
> > yet been answered (or maybe not answered to his satisfaction, I'm not
> > sure) but that if those were addressed he would take a look with a view
> > to acking the interface for inclusion in xen.git.
> 
> OK. So this means there are some concrete lose ends, which need to be followed up on. I also remember that there was a discussion on how we should specify protocols, which does not appear to have fully concluded either. 
> 
> >> 
> >> Would this work as a way forward?
> > 
> > I think the main things which is missing is some decision as to the the
> > point at which we would consider the ABI for a PV protocol fixed, i.e.
> > to be maintained in a backwards compatible manner from then on. 
> 
> What do we do with new APIs in such situations?

We review then carefully and hope we get them right. We manage to get
this right at least some of the time because many of us are familiar
with the issues WRT e.g. memory management hypercalls.

This is what I was getting at with "people are naturally a bit cautious
about creating new ABIs, which must be maintained long term, for types
of device with which they are not really familiar." in my initial mail.
The "which they are not really familiar" is pretty key.

It's also (normally) not too hard to add a new hypercall fixing a
shortcoming in an existing one while retaining backwards compat,
compared with doing that for an I/O protocol (see: netchannel2).

In the I/O case adding extensions also is reasonably well understood and
something we manage, but fixing a core issue is much harder (see: the
non-uniformity of the blk protocol over different architectures, or the
ring space wastage due to various power of two requirements, neither of
which can realistically be properly fixed).

Ian.