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

[Artem Mygaiev <artem.mygaiev@xxxxxxxxxxxxxxx>]

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

Well, we do not have enough manpower to support "forks", otherwise we
would create one somewhere long time ago. We want to a single work
tree which we can use for development so it may have some _temporary_
hacks - and this is something we want to avoid! but it is not always
possible. And we need a single tree since we are adding continuous
integration and automated testing of xen on embedded platform(s). Of
course, we will need to synchronise frequently, and we have someone to
be responsible for this to not deviate from the mainline. Having said
that, I perfectly understand your concerns - there are thousands of
useless abandoned project forks in OSS world...

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

pvdrivers.git shall not be a clone for xen.git. Indeed, it is a set of
drivers that, as you said, do not have a home in xen.git or kernel.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?

There will be no repos derived from xen.git in the pvdrivers.git

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

It seem to me that use of /people/ for subprojects may be misleading,
too... The goal of our integration tree is to serve as a staging tree
before upstreaming, hold all temporary hacks to support platforms and
specific use cases and also for the needs of ci and qa... Having that
code tested and working on automotive platforms like J6 we could be
able to involve our clients to xen. Would something like
xen.org/automotive.git or whatever similar be possible?

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

We would not mix userspace or non-Linux drivers with xen repo or Linux
repo. We do believe that this shall be a separate project.

Artem Mygaiev | AVP - Delivery
GlobalLogic
P +380.44.4929695 ext.2023 M +380.67.9211131 S rosenkrantzguildenstern
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

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