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

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

[-- Attachment #1.1: Type: text/plain, Size: 5616 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 28162 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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