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

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

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

On 06/06/2014 09:59, Ian Campbell wrote:
> On Thu, 2014-06-05 at 13:47 +0100, Artem Mygaiev wrote:
>
>>>> [need input] Should these be owned by a separate subproject or
>>>> attached to an existing subproject (e.g. the Hypervisor project)
>>>>
>>> So, I may be very wrong and/or missing something but I think we should
>>> distinguish between what code/changes are required in Xen and what
>>> outside from it.
>>>
>>> It would, probably, be useful to have a more clear view of that. What
>>> I'm thinking is, for each one of these new drivers, what are the
>>> modifications required in Xen, and what instead lives in the various
>>> OSes? Since we're talking about backends and frontends, I expect the
>>> latter for most of the code.
>> We tend to separate Xen core changes and PV drivers changes. Xen changes
>> are always posted separately, our intention is to upstream everything
>> that makes sense to have in the mainline (i.e. no hacks, workarounds,
>> etc. - that must not leave staging tree)
> I'm a bit concerned about this, since it sounds to me like it will
> eventually result in an automotive fork of xen.git.
I don't think this is the intention and *should not* be the intention. 
We are mixing up a long-term-home for official Xen Project PV drivers 
that don't fit elsewhere, such as
* QNX
* Maybe Linux user drivers (still waiting David Vrabel's view elsewhere 
on this thread)
* Other OS'es
which is the subject of this discussion.

Officially supported Xen Project repositories should only depend on 
*upstreams* (Xen, Linux, ...). As we are talking about 
git://xenbits.xen.org/pvdrivers.git here (as suggested by Aertem), 
whatever is in that repo (owned by a subproject) should build and work 
with vanilla Xen and Linux.

For everything else - call it a personal or integration tree - we have 
git trees in git://xenbits.xen.org/people/* ... a bit more below.

>>> I'm saying/asking this because, if the latter is the case, there seems
>>> to be no need for any alternative xen.git, mirroring Xen's code or
>>> anything. As said above, if something has to change in Xen, that should
>>> go through upstream.
>>> Probably, personal branches on xenbits for a few Globalogic contributors
>>> could help the upstreaming process, in which case I hope they can get
>>> them, but nothing more than that... Or, perhaps, I am missing or
>>> misreading something badly? :-)
>> You are absolutely right, but as I wrote above, we would like to suggest
>> having a staging tree for automotive/embedded stuff.
> Can't individual developers simply keep stuff in their personal trees or
> branches? If it then goes upstream that's great, but if it is an
> unsuitable "hack" then keeping it in a persons tree instead of in some
> formal subproject tree will neuter the possibility of an unintentional
> fork occurring.
I suppose the confusion comes from terminology here. The GlobalLogic 
guys talk about "integration" trees, which in practice (I believe) have. 
They just happen to be the personal branches of Xen committers under 
git://xenbits.xen.org/people/*

So there are several ways of how this could be handled:
* GlobalLogic nominates one person (let's say Andrii as an example) and 
we may have git://xenbits.xen.org/people/andrii/xen.git, 
git://xenbits.xen.org/people/andrii/linux.git and 
git://xenbits.xen.org/people/andrii/pvdrivers.git which in essence 
becomes the "integration tree" for automotive/embedded work
** A slight variant may be to group people by interest, e.g. 
git://xenbits.xen.org/people/embedded or 
git://xenbits.xen.org/embedded/people to make it easier to spot who 
works on what - and assume that if there was no qualifier they work on 
the hypervisor. We had done this for Hg in the past with XCP: so this is 
not entirely new.
* Or we could create something like 
git://xenbits.xen.org/integration/pvdrivers/*.git or 
git://xenbits.xen.org/people/integration/pvdrivers/*.git which may be 
shared by several people, but these could be treated as if they were in 
"people".
* Or a combination of the above

They may be subtle differences in "risks" of creating a fork, but on the 
other hand GlobalLogic already has it's own non-public fork within their 
org. In reality we are all working on ensuring there is no fork in the 
long-run.

@Ian Jackson: this probably needs to be resolved before we create the 
personal branches for GlobalLogic, as the two things are dependant.

>>> This lead us to where the actual code of the frontends and backends
>>> --i.e., the component _outside_ Xen-- should live. In the best possible
>>> world, the answer would be upstream Linux, upstream QNX, etc. However
>>> (although I think that should be the long term goal), I appreciate that
>>> such thing can take a while to actually happen. In the meanwhile, it
>>> would be great to have the code somewhere, so that people can download
>>> it, compile it, and run it in their Dom0 and guest of choice. For this,
>>> I totally see how a (sub)project repo (the 'pvdrivers' repo we were
>>> talking about above) can help.
>> Correct, this is our intention. Also, we dont think that QNX will ever
>> accept our code :) They are too OSS un-friendly...
> I think you need to decide the correct home on a per-OS basis.
It seems there seem to be agreement that per-OS is the best way forward

> e.g. Linux and BSD are OSS (and contribution) friendly so driver changes
> to those should always be done in the appropriate upstream, and
> therefore you don't require a subproject tree for them (individual
> developers can still have personal staging trees of course).
Can someone enlighten me why Linux user-space drivers may be different? 
This has come up at the BoF at the Dev Summit and also in this thread 
and is the only area where there is no full agreement on the way forward.

> If something like qnx is not OSS/contribution friendly then clearly does
> need it's own tree in the subproject. I think it would be up to you if
> you wanted to have a tree per-OS in that class or a single shared tree
> for all of them.
Sounds reasonable

Lars

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

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

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