Re: [Xen-devel] [Need Input] (informal) Automotive PV drivers subproject request

[Lars Kurth <lars.kurth@xxxxxxx>]

Artem, Xen community,

based on prior discussion with Artem and the session at the Hackathon I asked Artem to outline a pre-cursor for a proposal for a new offical Xen Project git repo and frame the question whether we should associate it to the Hypervisor subproject or whether we should propose a new subproject. This is really the context of this mail.

Also see, http://lists.xenproject.org/archives/html/xen-devel/2014-06/msg00289.html for the Hackathon minutes

There is a separate discussion for a few personal repos on xenbits, which is waiting for some information. But does not require a community discussion.

== important ==
I marked items, which require community input as [need input] below. Based on discussion and feedback, I would suggest to create a subproject proposal or otherwise.

On 04/06/2014 14:04, Artem Mygaiev wrote:

As a part of effort on bringing Xen into Automotive (and thus Embedded)
space, we are working on a set of PV drivers needed to share
peripherals between domains.
 * PV audio - new driver using ALSA
 * PV USB - based on old existing PV USB solution
 * PV framebuffer - modifications and improvements for existing FB
 * PV events - new driver for sharing HIDs across domains (touchscreen,
   keyb, etc.)

So just to clarify. The proposal here is to create another top-level git *.git tree alongside xen.git
@Artem, @Andrii

That raises a number of questions:

[need input] What name? posibilities are "automotive-pvdrivers, "embedded-pvdrivers", "pvdrivers", ...

[need input] Taking a slightly wider view, I know there was some discussion related to upstreaming RT-Xen. How does this fit in? Would there maybe be a case for "embedded/pvdrivers", "embedded/schedulers", ...

[need input] Should these be owned by a separate subproject or attached to an existing subproject (e.g. the Hypervisor project)

My personal view is that we should not create any offical new Xen Project codebases outside a subproject. Otherwise we will run into problems at some point. Do note, that this is a case we have not been through:
* in the case of Xen on ARM the project goal was to upstream changes to the hypervisor (we created a subproject to inbcrease visibility)
* Mirage OS was clearly a separate codebase and project already

There are trade-offs to either decision
* The key benefits of a separate subproject are commit access and project leadership for GlobalLogic. And consequently less burden on the existing Xen Project committer base.
* Improved visibility and PR value : this would be beneficial for a new subproject as well as the Xen Project as a whole. It would show increased momentum for the Xen project overall, while keeping the message to the market clear.
* A subproject would also avoid the situation that there is no clear governance and set of expectations around the code and a subproject goal: something we suffered from with the old ARM PV port (admittedly we didn't have governance then). In other words we have clear governance framework if,
a) the worst case happens and the drivers start to become unmaintained and,
b) if the best case happens and we suddenly get a lot of interest and there are arguments about ownership, process, decision making, ...
* The option of separate infrastructure, e.g. a separate mailing list, would reduce trhe barrier of entry to the new subproject

This list is not final, other things are to be added later on. Each
driver consists, obviously, of frontend and backend which may be
implemented for different OSes. So far only Linux is supported, QNX is
wip, ArcCore or similar being considered. Due to this, each driver has
following structure (sample):
/pv_audio
  /linux-alsa-be
  /linux-fe
  /qnx-be
  /qnx-fe

[need input] I suppose the long-term question here is whether "pvdrivers/pvaudio/*" or "pvdrivers/qnx/pvaudio/*" is better in the long run. Part of it comes down to any headers and other stuff is needed to build drivers for the like of "qnx". Cutting components by OS, aka "pvdrivers/qnx/*", ... may also be cleaner from a licensing and ownership perspective (e.g. say another OS is added by a company called "foobar")

Linux kernel code is developed under GPLv2 license, userspace
components like some backends are under Apache 2 license, so can be
integrated into software with commercial licenses.

That is fine for subprojects in principle. Of course we prefer GPL, but any OSI approved license is fine (see http://opensource.org/licenses/alphabetical).

QNX and other OSes
will have licenses that are required by corresponding regulations, some
may be not open nevertheless we tend to make all parts of the code
available to the Xen community.

Artem, Andrii: Just to clarify
* Can QNX drivers be built a) on Linux and b) without requiring to purchase QNX
* Are there any issues with QNX driver headers : in other words, can these be included under OSI approved licenses ?
* I suppose there is also some unclarity about which Linux drivers would live in Linux (and which in this repo). Can we try and establish a more concrete list?

As a starting point in publishing the code we would like to request for
creation of a dedicated project where these drivers could be maintained
by us (GlobalLogic) and available to the community for use, and
hopefully, further development.

Artem, Andrii: Just to clarify
* short term: did you mean the personal branches we already discussed?
* and longer term: conclude this discussion such that we can find an official home for those drivers

Best Regards
Lars

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