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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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

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

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

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.

Ian.


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