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

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

> On 23 Feb 2015, at 17:41, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> On Fri, 2015-02-06 at 13:28 +0200, Oleksandr Dmytryshyn wrote:
>> This is ABI for the two halves of a Para-virtual
>> sound driver to communicate with each to other.
>> 
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx>
>> Signed-off-by: Iurii Konovalenko <iurii.konovalenko@xxxxxxxxxxxxxxx>
> 
> This seems to have gotten rather stalled, I think because of two
> factors, one is that noone has clear maintainer responsibility for
> blessing the creation of new PV protocols and partly because 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.
> 
> I've added Lars because perhaps there is some process we can put in
> place which helps alleviate these issues. (I don't know what, but
> perhaps a "staging area" for new protocols which isn't ABI stable along
> with some sort of graduation process, or perhaps some sort of governance
> thing which would make it clear who has to say yes to something like
> this, so we can beat them with sticks until they say something).

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.

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?

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