On gio, 2014-06-05 at 13:47 +0100, Artem Mygaiev wrote:
> Hi Dario, all
> 
Hey!

> > IMHO, something like 'embedded-pvdrivers', i.e., a little bit more
> > generic than _automotive_-xxx, is better. Perhaps we can have something
> > even more generic, like 'pvdrivers' or 'additional-pvdrivers' and, if
> > necessary, have branches there (e.g., an automotive branch).
> 
> I would suggest to go with "pvdrivers" since we do not stick to just
> automotive or embedded
>
Right.

> Well, we are ready to upstream all the RT-Xen changes to RT-Xen, but
> probably it is a good time to start thinking if some stuff out there can
> be upstreamed to Xen mainline?
>
It is indeed.

> Who would be able to drive that?
> 
Work is already ongoing. A bunch of people are working on making this
happen, and I'm (doing my best at) coordinating such efforts. :-)

> > 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)
> 
Oh, I see. So, ideally, it's how I said: all Xen changes upstream. In
practice, however, that is a bit tricky. I actually appreciate that this
is the case. I'd be tempted to ask what kind of hacks, how big, how
intrusive, etc, but I don't want to get into too many details in this
thread.

It looks like we do need a mirror/copy/whatever of the Xen git tree,
then. This leaves open Lars' question of where it should live.
Personally, I don't think it would be terrible to have a full fledged
and shiny subproject for the additional pvdrivers, and have the 'hacked
Xen' repo be someone's personal development tree (once a bunch of you
guys get repositories on xenbits)... After all, in a wiki page with all
the instructions on how to checkout and build everything, all one needs
is some place where to point `git clone ...', isn't it?

Anyway... Let's see what others think...

> > 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...
> 
Yep, I've got some experience with that beast :-/

> > I mean, if I want to run Linux as Dom0 and QNX as DomU, I don't need QNX
> > backends, and I'd be happy to be able not to download/build them.
> 
> Absolutely. We can structure the code in any way, we just need to ensure
> it is convenient for community to work with it and there are no subtle
> dependencies... Grouping by OS makes sense - there might be some PV drivers
> available for one OS and not available for another.
> 
Indeed.

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)