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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 17 Mar 2015, Ian Campbell 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.
> 
> (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.

I think that you are right. Declaring the interface stable or unstable
is far more important than where the code or the spec lives.

If we formally specified within the spec that the ABI is not maintained
for backward compatibility, the bar for acceptance in xen-unstable would
be far lower. Maybe the spec could even be accepted as is if nobody has
any comments?

_______________________________________________
Embedded-pv-devel mailing list
Embedded-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/embedded-pv-devel