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

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

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.

(I've not looked in the threads for it, so I don't know the exact
state).

> From my perspective, this exactly the kind of scenario why we created
> the embedded / automotive subproject, with an option to store code in
> repos owned by the project. 
> 
> Given that the primary use-case of these drivers is embedded /
> automotive, my suggestion would be to
> 1.a) Use a repo in the embedded / automotive pv driver subproject to
> host the spec - but use a file system structure that matches the xen
> tree
> 1.b) I would assume there would be one back-end and several front-ends
> for these drivers and some would eventually appear in trees owned by
> the embedded / automotive pv driver subproject
> 
> In this case, the maintainer responsibility would fall to members of
> the embedded / automotive pv driver subproject. Once there are several
> implementations, and enough people with skills to review we can
> re-visit where the spec and drivers live. 
> 
> We can have a discussion about criteria of when to move, but I don't
> think that makes a lot of sense. I think the concerns that need to be
> addressed are:
> 2.a) Enough skills to review the code / protocols from different
> stake-holders - this should happen with time, once the spec and code
> are there. And of course once the embedded / automotive pv driver
> subproject graduates, that will also give extra weight to its
> maintainers in the wider community
> 2.b) Of course if there was a strong case that PV sound drivers are
> extremely useful for core data centre use-cases, I would probably
> suggest another approach
> 
> Maybe 2.b) needs to be checked with Intel folks - there may be some
> sound requirement for XenGT
> 
> 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. 

That's of particular importance when one end of the pair is implemented
in external projects (e.g. OS driver frontends). If the interface is not
declared stable then changes would be allowed which would invalidate
those drivers.

Ian.