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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-06-06 at 14:05 +0100, Lars Kurth wrote:
> 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.

Perhaps should be the subject of this discussion, but we had somehow
ended up talking about Xen core changes. In particular there was talk of
putting things into these staging trees which it was known would not go
upstream ("things which should not leave staging tree"). At that point
they are no longer a staging tree, they are a fork. That was what caused
me to bring up my concern about forking.

> 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.

Is this pvdrivers.git going to be a descendent (e.g. a git clone) of
xen.git? Or is it a fresh repository which contains this new set of
drivers which do not have a home in xen.git?

Are there going to be are repos in this new subproject which are derived
from xen.git? What will be in them (hypervisor patches?) and what is
intended to happen with them?

> > > > 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.

Is a word missing from the last sentence? "they" perhaps? Or "we"?

>  They just happen to be the personal branches of Xen committers under
> git://xenbits.xen.org/people/* 

Not just committers.

I'm not really sure what you mean by "integration" trees. I suppose some
of the trees under there might be "integration" trees most of them are
just peoples various personal repos which they use for
exchanging/referencing patches, sending branches as pull requests,
sharing WIP stuff with random others etc. 

Ultimately what people keep in their personal trees under
git://xenbits.xen.org/people/ is entirely their business (licensing,
copyright relevance to xen etc aside), I don't think we should conflate
that with subproject trees and "official" stuff.

> 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

There seems to be a lot of mixing the concept of personal git trees with
git trees related to subprojects, or at least it isn't always clear
which one people are talking about. The two are very different things
IMHO and it's not clear to me how any of the proposals you make above
other than the first (the Andrii has a personal tree option) relates to
the proposed new project being discussed in this thread.

Putting subproject trees under /people/, which I'm not sure if you are
proposing or not in some of the above options, is confusing.

> 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.

> > 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?

There is no "upstream Linux user-space driver" project which these
drivers can be contributed to. So either we become that upstream for Xen
related drivers, or a new pvdrivers project does.

>  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.

Ian.


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