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