Automotive PV drivers project request

Automotive PV drivers project request

[Artem Mygaiev]

As a part of effort on bringing Xen into Automotive (and thus Embedded)
space, we are working on a set of PV drivers needed to share
peripherals between domains.
 * PV audio - new driver using ALSA
 * PV USB - based on old existing PV USB solution
 * PV framebuffer - modifications and improvements for existing FB
 * PV events - new driver for sharing HIDs across domains (touchscreen,
   keyb, etc.)
This list is not final, other things are to be added later on. Each
driver consists, obviously, of frontend and backend which may be
implemented for different OSes. So far only Linux is supported, QNX is
wip, ArcCore or similar being considered. Due to this, each driver has
following structure (sample):
/pv_audio
  /linux-alsa-be
  /linux-fe
  /qnx-be
  /qnx-fe
Linux kernel code is developed under GPLv2 license, userspace
components like some backends are under Apache 2 license, so can be
integrated into software with commercial licenses. QNX and other OSes
will have licenses that are required by corresponding regulations, some
may be not open nevertheless we tend to make all parts of the code
available to the Xen community.

As a starting point in publishing the code we would like to request for
creation of a dedicated project where these drivers could be maintained
by us (GlobalLogic) and available to the community for use, and
hopefully, further development.

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

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

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 5616 bytes --]

Artem, Xen community,

based on prior discussion with Artem and the session at the Hackathon I 
asked Artem to outline a pre-cursor for a proposal for a new offical Xen 
Project git repo and frame the question whether we should associate it 
to the Hypervisor subproject or whether we should propose a new 
subproject. This is really the context of this mail.

Also see, 
http://lists.xenproject.org/archives/html/xen-devel/2014-06/msg00289.html for 
the Hackathon minutes

There is a separate discussion for a few personal repos on xenbits, 
which is waiting for some information. But does not require a community 
discussion.

== important ==
I marked items, which require community input as [need input] below. 
Based on discussion and feedback, I would suggest to create a subproject 
proposal or otherwise.

On 04/06/2014 14:04, Artem Mygaiev wrote:
> As a part of effort on bringing Xen into Automotive (and thus Embedded)
> space, we are working on a set of PV drivers needed to share
> peripherals between domains.
>   * PV audio - new driver using ALSA
>   * PV USB - based on old existing PV USB solution
>   * PV framebuffer - modifications and improvements for existing FB
>   * PV events - new driver for sharing HIDs across domains (touchscreen,
>     keyb, etc.)
So just to clarify. The proposal here is to create another top-level git 
*.git tree alongside xen.git
@Artem, @Andrii

That raises a number of questions:

[need input] What name? posibilities are "automotive-pvdrivers, 
"embedded-pvdrivers", "pvdrivers", ...

[need input] Taking a slightly wider view, I know there was some 
discussion related to upstreaming RT-Xen. How does this fit in? Would 
there maybe be a case for "embedded/pvdrivers", "embedded/schedulers", ...

[need input] Should these be owned by a separate subproject or attached 
to an existing subproject (e.g. the Hypervisor project)

My personal view is that we should not create any offical new Xen 
Project codebases outside a subproject. Otherwise we will run into 
problems at some point. Do note, that this is a case we have not been 
through:
* in the case of Xen on ARM the project goal was to upstream changes to 
the hypervisor (we created a subproject to inbcrease visibility)
* Mirage OS was clearly a separate codebase and project already

There are trade-offs to either decision
* The key benefits of a separate subproject are commit access and 
project leadership for GlobalLogic. And consequently less burden on the 
existing Xen Project committer base.
* Improved visibility and PR value : this would be beneficial for a new 
subproject as well as the Xen Project as a whole. It would show 
increased momentum for the Xen project overall, while keeping the 
message to the market clear.
* A subproject would also avoid the situation that there is no clear 
governance and set of expectations around the code and a subproject 
goal: something we suffered from with the old ARM PV port (admittedly we 
didn't have governance then). In other words we have clear governance 
framework if,
a) the worst case happens and the drivers start to become unmaintained and,
b) if the best case happens and we suddenly get a lot of interest and 
there are arguments about ownership, process, decision making, ...
* The option of separate infrastructure, e.g. a separate mailing list, 
would reduce trhe barrier of entry to the new subproject

> This list is not final, other things are to be added later on. Each
> driver consists, obviously, of frontend and backend which may be
> implemented for different OSes. So far only Linux is supported, QNX is
> wip, ArcCore or similar being considered. Due to this, each driver has
> following structure (sample):
> /pv_audio
>    /linux-alsa-be
>    /linux-fe
>    /qnx-be
>    /qnx-fe
[need input] I suppose the long-term question here is whether 
"pvdrivers/pvaudio/*" or "pvdrivers/qnx/pvaudio/*" is better in the long 
run. Part of it comes down to any headers and other stuff is needed to 
build drivers for the like of "qnx". Cutting components by OS, aka 
"pvdrivers/qnx/*", ... may also be cleaner from a licensing and 
ownership perspective (e.g. say another OS is added by a company called 
"foobar")

> Linux kernel code is developed under GPLv2 license, userspace
> components like some backends are under Apache 2 license, so can be
> integrated into software with commercial licenses.
That is fine for subprojects in principle. Of course we prefer GPL, but 
any OSI approved license is fine (see 
http://opensource.org/licenses/alphabetical).

> QNX and other OSes
> will have licenses that are required by corresponding regulations, some
> may be not open nevertheless we tend to make all parts of the code
> available to the Xen community.
Artem, Andrii: Just to clarify
* Can QNX drivers be built a) on Linux and b) without requiring to 
purchase QNX
* Are there any issues with QNX driver headers : in other words, can 
these be included under OSI approved licenses ?
* I suppose there is also some unclarity about which Linux drivers would 
live in Linux (and which in this repo). Can we try and establish a more 
concrete list?

> As a starting point in publishing the code we would like to request for
> creation of a dedicated project where these drivers could be maintained
> by us (GlobalLogic) and available to the community for use, and
> hopefully, further development.
Artem, Andrii: Just to clarify
* short term: did you mean the personal branches we already discussed?
* and longer term: conclude this discussion such that we can find an 
official home for those drivers

Best Regards
Lars


[-- Attachment #1.2: Type: text/html, Size: 28162 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 8600 bytes --]

On mer, 2014-06-04 at 15:22 +0100, Lars Kurth wrote:
> Artem, Xen community,
> 
Hi everyone,

> There is a separate discussion for a few personal repos on xenbits,
> which is waiting for some information. But does not require a
> community discussion.
> 
> == important ==
> I marked items, which require community input as [need input] below.
> Based on discussion and feedback, I would suggest to create a
> subproject proposal or otherwise.
> 
I like the idea of the subproject too. More details below.

> On 04/06/2014 14:04, Artem Mygaiev wrote:
> 
> > As a part of effort on bringing Xen into Automotive (and thus Embedded)
> > space, we are working on a set of PV drivers needed to share
> > peripherals between domains.
> >  * PV audio - new driver using ALSA
> >  * PV USB - based on old existing PV USB solution
> >  * PV framebuffer - modifications and improvements for existing FB
> >  * PV events - new driver for sharing HIDs across domains (touchscreen,
> >    keyb, etc.)
> So just to clarify. The proposal here is to create another top-level
> git *.git tree alongside xen.git 
> @Artem, @Andrii
> 
> That raises a number of questions:
> 
> [need input] What name? posibilities are "automotive-pvdrivers,
> "embedded-pvdrivers", "pvdrivers", ...
> 
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).

Let's hear @Artem and @Andrii, though, as I think their opinion, as the
main contributors (at least for now) for this repo, is quite
important. :-)

> [need input] Taking a slightly wider view, I know there was some
> discussion related to upstreaming RT-Xen. How does this fit in? Would
> there maybe be a case for "embedded/pvdrivers",
> "embedded/schedulers", ... 
> 
Not really, IMO. The idea there is not to "upstream RT-Xen". It is,
OTOH, "extract the best from RT-Xen and upstream that properly, as _the_
real-time scheduling solution for Xen".
Of course, contributions from all the others that have been working on
Real-Time scheduling on Xen are also welcome, but the point is that we
do want a working RT scheduling solution (replacing SEDF, which is not
functional any longer), and we want it upstream, not in a branch, in a
subproject, or anywhere else. :-)

This approach, I think, applies to most of the Xen components of
Globalogic's work. I mean, as usual, the goal should be to upstream
*everything*, unless there is something that can't live upstream for
some good reason... Is that the case?

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

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

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.

> My personal view is that we should not create any offical new Xen
> Project codebases outside a subproject. Otherwise we will run into
> problems at some point. 
>
Indeed.

> Do note, that this is a case we have not been through: 
> * in the case of Xen on ARM the project goal was to upstream changes
> to the hypervisor (we created a subproject to inbcrease visibility)
> * Mirage OS was clearly a separate codebase and project already
> 
As said, I'm not sure how much this case is different. @Artem? Is the
situation (almost) as black-and-white as I see it? Or are there a lot of
Xen changes required for your fe/be to actually work? If there are a lot
of Xen changes required, how 'upstreamable' (do you think) are they?

> There are trade-offs to either decision
> * The key benefits of a separate subproject are commit access and
> project leadership for GlobalLogic. And consequently less burden on
> the existing Xen Project committer base. 
>
The fe and be code and repo should definitely be owned --and the
development led-- by Globalogic... They're doing a great job at that in
any case already, so... :-P :-P

> * Improved visibility and PR value : this would be beneficial for a
> new subproject as well as the Xen Project as a whole. It would show
> increased momentum for the Xen project overall, while keeping the
> message to the market clear.
>
Agreed.

> > This list is not final, other things are to be added later on. Each
> > driver consists, obviously, of frontend and backend which may be
> > implemented for different OSes. So far only Linux is supported, QNX is
> > wip, ArcCore or similar being considered. Due to this, each driver has
> > following structure (sample):
> > /pv_audio
> >   /linux-alsa-be
> >   /linux-fe
> >   /qnx-be
> >   /qnx-fe
> [need input] I suppose the long-term question here is whether
> "pvdrivers/pvaudio/*" or "pvdrivers/qnx/pvaudio/*" is better in the
> long run. Part of it comes down to any headers and other stuff is
> needed to build drivers for the like of "qnx". Cutting components by
> OS, aka "pvdrivers/qnx/*", ... may also be cleaner from a licensing
> and ownership perspective (e.g. say another OS is added by a company
> called "foobar")
> 
Well, even from a "user" perspective, I think the clearer the indication
of which code one should checkout/download for a specific OS, the
better...

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.

> > QNX and other OSes
> > will have licenses that are required by corresponding regulations, some
> > may be not open nevertheless we tend to make all parts of the code
> > available to the Xen community.
> Artem, Andrii: Just to clarify 
> * Can QNX drivers be built a) on Linux and b) without requiring to
> purchase QNX
> * Are there any issues with QNX driver headers : in other words, can
> these be included under OSI approved licenses ?
>
I agree this is one interesting bit to know.

> * I suppose there is also some unclarity about which Linux drivers
> would live in Linux (and which in this repo). Can we try and establish
> a more concrete list?
> 
Agreed.

> > As a starting point in publishing the code we would like to request for
> > creation of a dedicated project where these drivers could be maintained
> > by us (GlobalLogic) and available to the community for use, and
> > hopefully, further development.
> Artem, Andrii: Just to clarify 
> * short term: did you mean the personal branches we already discussed?
> * and longer term: conclude this discussion such that we can find an
> official home for those drivers
> 
I think both could be useful, in the sense that I tried to outline in
this email.... I hope I've made myself clear enough. :-)

Thanks (particularly to Artem for starting this) 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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Artem Mygaiev]

Hi Dario, all

> > [need input] What name? posibilities are "automotive-pvdrivers,
> > "embedded-pvdrivers", "pvdrivers", ...
> >
> 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
>
> > [need input] Taking a slightly wider view, I know there was some
> > discussion related to upstreaming RT-Xen. How does this fit in? Would
> > there maybe be a case for "embedded/pvdrivers",
> > "embedded/schedulers", ...
> >
> Not really, IMO. The idea there is not to "upstream RT-Xen". It is,
> OTOH, "extract the best from RT-Xen and upstream that properly, as _the_
> real-time scheduling solution for Xen".
> Of course, contributions from all the others that have been working on
> Real-Time scheduling on Xen are also welcome, but the point is that we
> do want a working RT scheduling solution (replacing SEDF, which is not
> functional any longer), and we want it upstream, not in a branch, in a
> subproject, or anywhere else. :-)

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? Who would be able to drive that?

> This approach, I think, applies to most of the Xen components of
> Globalogic's work. I mean, as usual, the goal should be to upstream
> *everything*, unless there is something that can't live upstream for
> some good reason... Is that the case?

Exactly!

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

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

> > Do note, that this is a case we have not been through:
> > * in the case of Xen on ARM the project goal was to upstream changes
> > to the hypervisor (we created a subproject to inbcrease visibility)
> > * Mirage OS was clearly a separate codebase and project already
> >
> As said, I'm not sure how much this case is different. @Artem? Is the
> situation (almost) as black-and-white as I see it? Or are there a lot of
> Xen changes required for your fe/be to actually work? If there are a lot
> of Xen changes required, how 'upstreamable' (do you think) are they?

There are not many Xen changes, most are not quite related to PV drivers.
But there are things that we need to have (mostly hacks/workarounds) to
support _real_ HW platforms, and we are working on cleaning that stuff
up, but it is not smth that can be done quickly. Nevertheless, we want
community to be able to start playing with it, contribute to code cleanup,
etc. Again, we are asking for the automotive/embedded staging tree.

> > > This list is not final, other things are to be added later on. Each
> > > driver consists, obviously, of frontend and backend which may be
> > > implemented for different OSes. So far only Linux is supported, QNX is
> > > wip, ArcCore or similar being considered. Due to this, each driver has
> > > following structure (sample):
> > > /pv_audio
> > >   /linux-alsa-be
> > >   /linux-fe
> > >   /qnx-be
> > >   /qnx-fe
> > [need input] I suppose the long-term question here is whether
> > "pvdrivers/pvaudio/*" or "pvdrivers/qnx/pvaudio/*" is better in the
> > long run. Part of it comes down to any headers and other stuff is
> > needed to build drivers for the like of "qnx". Cutting components by
> > OS, aka "pvdrivers/qnx/*", ... may also be cleaner from a licensing
> > and ownership perspective (e.g. say another OS is added by a company
> > called "foobar")
> >
> Well, even from a "user" perspective, I think the clearer the indication
> of which code one should checkout/download for a specific OS, the
> better...
>
> 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.

> > > QNX and other OSes
> > > will have licenses that are required by corresponding regulations, some
> > > may be not open nevertheless we tend to make all parts of the code
> > > available to the Xen community.
> > Artem, Andrii: Just to clarify
> > * Can QNX drivers be built a) on Linux and b) without requiring to
> > purchase QNX
> > * Are there any issues with QNX driver headers : in other words, can
> > these be included under OSI approved licenses ?
> >
> I agree this is one interesting bit to know.

a) yes, there is a QNX Momentics IDE available for Linux
b) there is an "academic" free license and also 30-day evaluation

> > * I suppose there is also some unclarity about which Linux drivers
> > would live in Linux (and which in this repo). Can we try and establish
> > a more concrete list?
> >
> Agreed.

Basically, we would be happy to avoid having a separate repo and make
everything integrated to Linux. But until it is accepted it can live in
"this repo". Framebuffer is already in the Linux so it shall be upstreamed
there...

> > > As a starting point in publishing the code we would like to request for
> > > creation of a dedicated project where these drivers could be maintained
> > > by us (GlobalLogic) and available to the community for use, and
> > > hopefully, further development.
> > Artem, Andrii: Just to clarify
> > * short term: did you mean the personal branches we already discussed?
> > * and longer term: conclude this discussion such that we can find an
> > official home for those drivers
> >
> I think both could be useful, in the sense that I tried to outline in
> this email.... I hope I've made myself clear enough. :-)

Yes, this is what I mean (both).

Best regards,
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

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

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 3939 bytes --]

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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Ian Campbell]

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.

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

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 6077 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 12482 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Ian Campbell]

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.

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

[Artem Mygaiev]

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

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

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 5127 bytes --]

On Fri, 2014-06-06 at 22:49 +0300, Artem Mygaiev wrote:
> > 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. 
>
Well... I can't comment on the amount of manpower, but I'm happy that
there's not a Xen-automotive fork, and that we're discussing this here,
at least! :-D

> 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...
> 
Exactly. So, as I already first suggested and as Ian restated, I don't
see the problem if this stating/temporary/integration/whatever tree is
someone's personal tree.

And I'm not saying that we should have subproject repo(s) under
xenbits.org/people, I'm saying that, to get the bleeding edge of Xen for
automotive, the version that supports all the feature and all the
pvdrivers on all OSes, etc, you should clone and build Artem's git tree,
or Andrii's one, or whatever other one...

After all, although this predates my involvement in Xen, it's not long
ago that, if one wanted to use Xen as Dom0, with all the coolest
features, he needed to clone and track Jeremy's tree, or Konrad's one,
is it?

The only thing that needs, IMHO, to be clear, is whether or not there
are non-upstreamable bits, and I'm talking about non-upstreamable in the
long term. If there are, we've got a problem (and perhaps we should
store the patches somewhere, as Ian was also said, or something like
that). If there are not, if the goal is to upstream everything in
xen.git and if we think such goal to be reasonable, and the problem is
"only" <<but what about in the meantime>>, well, xenbits.org/people/xxx
seems fine to me.

After all, it's all a matter of what you tell people to clone and track,
and on how you manage such tree yourself, deal with contributions from
others, etc.

What's wrong with this approach?

> >> 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
> 
Indeed. What I've got in mind is something like the following:

xenbits.org/[artem?]/xen-automotive.git  integration tree
xenbits.org/pvdrivers.git    'additional pvdrivers' (subproject?) tree

I concur with Ian that the latter should host everything that does not
have any proper upstream (like linux userspace components), or that
can't be upstreamed for non technical reasons (like QNX components).
What I'd allow is probably for some Linux *kernel* components, just out
of convenience, although, again, I think the goal there should be
similar to what we said wrt Xen: *upstream them all*!! :-D

> > 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. 
>
Right. And if we call the pvdrivers the subproject, and put it somewhere
else than /people, but we keep the xen tree under people --and not call
it a subproject-- what's the problem your clients would face?

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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Stefano Stabellini]

On Sat, 7 Jun 2014, Dario Faggioli wrote:
> > >> 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
> > 
> Indeed. What I've got in mind is something like the following:
> 
> xenbits.org/[artem?]/xen-automotive.git  integration tree
> xenbits.org/pvdrivers.git    'additional pvdrivers' (subproject?) tree
> 
> I concur with Ian that the latter should host everything that does not
> have any proper upstream (like linux userspace components), or that
> can't be upstreamed for non technical reasons (like QNX components).
> What I'd allow is probably for some Linux *kernel* components, just out
> of convenience, although, again, I think the goal there should be
> similar to what we said wrt Xen: *upstream them all*!! :-D

It sounds like we are heading toward creating both personal trees and
pvdrivers.git.

The personal trees would be personal trees like everybody else's: they
could be used for WIP patch series and pull requests. They are no
different from mine and yours.

pvdrivers.git is the interesting one because it would be the upstream
git repository for otherwise homeless pv drivers, such us userspace and
QNX PV drivers.

In my opinion Linux kernel drivers should stay in their personal git
trees as WIP patch series until upsteamed.


On Fri, 6 Jun 2014, Artem Mygaiev wrote:
> > 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?

Given that the staging tree would be a Linux tree plus a collection of
non-upstreamable changes, I would keep it as a branch on one of your
personal repositories. After all in the Linux world it is common to keep
this kind of things as personal trees as you can see from
git.kernel.org.
Even the Linux tree that we used for OSSTests with Xen on ARM is just a
branch on my personal Linux git repository for example.

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

[Lars Kurth]

On 09/06/2014 11:18, Stefano Stabellini wrote:
> On Sat, 7 Jun 2014, Dario Faggioli wrote:
>>>>> 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
>>>
>> Indeed. What I've got in mind is something like the following:
>>
>> xenbits.org/[artem?]/xen-automotive.git  integration tree
I am assuming xen-automotive.git = xen.git with hacks (as a staging tree)
So wouldn't it be better the to have 
xenbits/people/automotive/artem?/xen.git instead of a renamed tree?

>> xenbits.org/pvdrivers.git    'additional pvdrivers' (subproject?) tree
>>
>> I concur with Ian that the latter should host everything that does not
>> have any proper upstream (like linux userspace components), or that
>> can't be upstreamed for non technical reasons (like QNX components).
>> What I'd allow is probably for some Linux *kernel* components, just out
>> of convenience, although, again, I think the goal there should be
>> similar to what we said wrt Xen: *upstream them all*!! :-D
Wouldn't that complicate merging, etc.  It actually would only become 
convenient for building and terrible for upstreaming
Which is why I argued for
* xenbits.org/pvdrivers.git = clean and purely dependent on
* xenbits.org/people/automotive/artem?/*.git to contain hacks for Linux 
kernel, etc.

The workflow would be:
* xenbits.org/people/automotive/artem?/*.git ... initial contribution 
and space to clean up hacks
* xenbits.org/pvdrivers.git ... clean repo reflecting what is upstream. 
This is the final destination for PV drivers not living elsewhere. This 
is where the pvdrivers subproject would make releases from, etc.

> It sounds like we are heading toward creating both personal trees and
> pvdrivers.git.
That was my assumption too. See earlier mail

> The personal trees would be personal trees like everybody else's: they
> could be used for WIP patch series and pull requests. They are no
> different from mine and yours.
Agreed
> pvdrivers.git is the interesting one because it would be the upstream
> git repository for otherwise homeless pv drivers, such us userspace and
> QNX PV drivers.
Agreed
>
> In my opinion Linux kernel drivers should stay in their personal git
> trees as WIP patch series until upsteamed.
Agreed

Regards
Lars

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

[Ian Campbell]

On Mon, 2014-06-09 at 13:25 +0100, Lars Kurth wrote:
> On 09/06/2014 11:18, Stefano Stabellini wrote:
> > On Sat, 7 Jun 2014, Dario Faggioli wrote:
> >>>>> 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
> >>>
> >> Indeed. What I've got in mind is something like the following:
> >>
> >> xenbits.org/[artem?]/xen-automotive.git  integration tree
> I am assuming xen-automotive.git = xen.git with hacks (as a staging tree)
> So wouldn't it be better the to have 
> xenbits/people/automotive/artem?/xen.git instead of a renamed tree?

Please can we keep subproject names out of the people namespace, it's
just confusing things (i.e. is that an official repo of some sort or
not?). /people/artem/xen.git is perfectly fine as a name for Artem's
repo.

Ian.

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

[Lars Kurth]

On 09/06/2014 13:30, Ian Campbell wrote:
> On Mon, 2014-06-09 at 13:25 +0100, Lars Kurth wrote:
>> On 09/06/2014 11:18, Stefano Stabellini wrote:
>>> On Sat, 7 Jun 2014, Dario Faggioli wrote:
>>>>>>> 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
>>>>>
>>>> Indeed. What I've got in mind is something like the following:
>>>>
>>>> xenbits.org/[artem?]/xen-automotive.git  integration tree
>> I am assuming xen-automotive.git = xen.git with hacks (as a staging tree)
>> So wouldn't it be better the to have
>> xenbits/people/automotive/artem?/xen.git instead of a renamed tree?
> Please can we keep subproject names out of the people namespace, it's
> just confusing things (i.e. is that an official repo of some sort or
> not?). /people/artem/xen.git is perfectly fine as a name for Artem's
> repo.

/people/artem/xen.git is fine with me.
Lars

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

[Lars Kurth]

As an aside,

it looks to me as if we were close enough to draft a subproject proposal 
on the wiki. As far I can see we agreed on
* we need a subproject
* we need an official xenbits.org/pvdrivers.git repo; it would also come 
with its own mailing list if desired
* we agreed what can and cannot be in xenbits.org/pvdrivers.git
* we agreed on licenses
* in addition we need integration branches for xen.git, linux.git, 
pvdrivers.git - it appears that the consensus here is that we use the 
same pattern as elsewhere
(aka the location for the staging branch is in xenbits.org/people). 
Maybe with some mods, e.g. people/automotive/* instead of people/* - 
although this is not yet finally agreed. There are still differing 
opinions on naming.

The proposal should probably clarify some of the points raised in the 
thread, to remove any confusion.

Regards
Lars

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

[Ian Jackson]

Lars Kurth writes ("Re: [Xen-devel] [Need Input] (informal) Automotive PV drivers subproject request"):
> As an aside,
> 
> it looks to me as if we were close enough to draft a subproject proposal 
> on the wiki. As far I can see we agreed on
> * we need a subproject

I would just like to quibble with your pathnames.  I think that the
subproject should have its own subdirectory, which should contain all
of its repos.

So:

> * we need an official xenbits.org/pvdrivers.git repo; it would also come 
> with its own mailing list if desired
> * in addition we need integration branches for xen.git, linux.git, 
> pvdrivers.git - it appears that the consensus here is that we use the 
> same pattern as elsewhere

Rather, we should have:

  xenbits.xen.org/automotive/pvdrivers.git
  xenbits.xen.org/automotive/linux.git
  xenbits.xen.org/automotive/xen.git
  etc.

(FSVO "automotive"; I currently have no opinion about the project
name.)

Cf xenbits.xen.org/xenclient/, xenbits.xen.org/kemari/,
xenbits.xen.org/xcp/, xenbits.xen.org/xenrt-citrix/ ...


NB these are mostly git url fragments, not http url fragments.  So eg
"xenbits.xen.org/xenrt-citrix/" contains "xenrt.git" which is
accessible via
  git clone git://xenbits.xen.org/xenrt-citrix/xenrt.git
(and also via the gitweb index etc.)

If it is helpful there is no technical reason why it would be
difficult to provide a subproject with a webtree on xenbits that would
be accessible via http://xenbits.xen.org/subproject/.  But we don't
want xenbits to be used for general-purpose web hosting.

AIUI this particular subproject doesn't have a requirement at this
stage for a separate web hosting setup.


> (aka the location for the staging branch is in xenbits.org/people). 
> Maybe with some mods, e.g. people/automotive/* instead of people/* - 
> although this is not yet finally agreed. There are still differing 
> opinions on naming.

I agree with Ian Campbell that we do not want subproject names in
people/.  That is strictly for human beings, and contains only
"unofficial" repos.

Thanks,
Ian.

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

[Lars Kurth]

On 09/06/2014 14:12, Ian Jackson wrote:
> Lars Kurth writes ("Re: [Xen-devel] [Need Input] (informal) Automotive PV drivers subproject request"):
>> As an aside,
>>
>> it looks to me as if we were close enough to draft a subproject proposal
>> on the wiki. As far I can see we agreed on
>> * we need a subproject
> I would just like to quibble with your pathnames.  I think that the
> subproject should have its own subdirectory, which should contain all
> of its repos.
I don't mind. I missed the convention you outlined

> So:
>
>> * we need an official xenbits.org/pvdrivers.git repo; it would also come
>> with its own mailing list if desired
>> * in addition we need integration branches for xen.git, linux.git,
>> pvdrivers.git - it appears that the consensus here is that we use the
>> same pattern as elsewhere
> Rather, we should have:
>
>    xenbits.xen.org/automotive/pvdrivers.git
>    xenbits.xen.org/automotive/linux.git
>    xenbits.xen.org/automotive/xen.git
>    etc.
>
> (FSVO "automotive"; I currently have no opinion about the project
> name.)
That would make sense. So we follow the convention 
xenbits.xen.org/<subproject name>/pvdrivers.git

However, if we allowed linux.git and xen.git in 
xenbits.xen.org/<subproject name>, it does increase the risk of creating 
a permanent fork (i.e. the main concerns raised by IanC, Stefano, etc.)

> Cf xenbits.xen.org/xenclient/, xenbits.xen.org/kemari/,
> xenbits.xen.org/xcp/, xenbits.xen.org/xenrt-citrix/ ...
>
>
> NB these are mostly git url fragments, not http url fragments.  So eg
> "xenbits.xen.org/xenrt-citrix/" contains "xenrt.git" which is
> accessible via
>    git clone git://xenbits.xen.org/xenrt-citrix/xenrt.git
> (and also via the gitweb index etc.)
>
> If it is helpful there is no technical reason why it would be
> difficult to provide a subproject with a webtree on xenbits that would
> be accessible via http://xenbits.xen.org/subproject/.  But we don't
> want xenbits to be used for general-purpose web hosting.
>
> AIUI this particular subproject doesn't have a requirement at this
> stage for a separate web hosting setup.
I wasn't aware of it. And we don't need it

>> (aka the location for the staging branch is in xenbits.org/people).
>> Maybe with some mods, e.g. people/automotive/* instead of people/* -
>> although this is not yet finally agreed. There are still differing
>> opinions on naming.
> I agree with Ian Campbell that we do not want subproject names in
> people/.  That is strictly for human beings, and contains only
> "unofficial" repos.
OK.

Regards
Lars

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

[Artem Mygaiev]

[-- Attachment #1.1: Type: text/plain, Size: 1332 bytes --]

>
> So:
>>
>>  * we need an official xenbits.org/pvdrivers.git repo; it would also come
>>> with its own mailing list if desired
>>> * in addition we need integration branches for xen.git, linux.git,
>>> pvdrivers.git - it appears that the consensus here is that we use the
>>> same pattern as elsewhere
>>>
>> Rather, we should have:
>>
>>    xenbits.xen.org/automotive/pvdrivers.git
>>    xenbits.xen.org/automotive/linux.git
>>    xenbits.xen.org/automotive/xen.git
>>    etc.
>>
>> (FSVO "automotive"; I currently have no opinion about the project
>> name.)
>>
> That would make sense. So we follow the convention xenbits.xen.org/<subproject
> name>/pvdrivers.git
>

​I like the idea :)​

However, if we allowed linux.git and xen.git in xenbits.xen.org/<subproject
> name>, it does increase the risk of creating a permanent fork (i.e. the
> main concerns raised by IanC, Stefano, etc.)


​True. But this is always a risk (like with mentioned XenRT), even without
staging trees in subprojects​. To me it is more a matter of maintainers'
and community discipline...

Artem Mygaiev | AVP - Delivery
GlobalLogic
P +380.44.4929695 ext.2023 M +380.67.9211131 S rosenkrantzguildenstern
www.globallogic.com
<http://www.globallogic.com/>
http://www.globallogic.com/email_disclaimer.txt​

[-- Attachment #1.2: Type: text/html, Size: 4049 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 867 bytes --]

On 10/06/2014 15:22, Artem Mygaiev wrote:
>
>     However, if we allowed linux.git and xen.git in xenbits.xen.org/
>     <http://xenbits.xen.org/><subproject name>, it does increase the
>     risk of creating a permanent fork (i.e. the main concerns raised
>     by IanC, Stefano, etc.)
>
>
> ​True. But this is always a risk (like with mentioned XenRT), even 
> without staging trees in subprojects​. To me it is more a matter of 
> maintainers' and community discipline...
How about xenbits.xen.org/ <http://xenbits.xen.org/><subproject 
name>/staging/ for the staging trees, if there is consensus to do this.
But we can leave this open for now: it's not blocking us from moving forward

I have enough to work on a formal subproject proposal and started at 
http://wiki.xenproject.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal

Regards
Lars






[-- Attachment #1.2: Type: text/html, Size: 2197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Lars Kurth]

On 06/06/2014 20:49, Artem Mygaiev wrote:
>>>>>>> [need input] Should these be owned by a separate subproject or
>>>>>>> attached to an existing subproject (e.g. the Hypervisor project)
[snip]
>> 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?
Sorry for the confusion. What I was trying to say:
* We would have an official tree pvdrivers.git tree owned by the 
subproject aka xenbits/pvdrivers.git alongside xenbits/xen, which works 
with upstream linux and xen.git. No hacks allowed in there.
* In *addition* we would need integration or personal repos (however we 
want to call them) as work-in-progress and development branches for 
linux, xen and pvdrivers.git - these could contain some hacks for a 
limited period. The reason is because the code as it is contains some 
dependencies on hacks elsewhere. This discussion was about the naming of 
the best naming convention for this integration tree.

I wasn't arguing for moving the official tree of the subproject into the 
people directory

>>> 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.
OK. This makes sense. So if we are all agreed pvdrivers.git can contain 
"user-space Linux drivers", but maybe we can label them by calling the 
directory in which these sit as linux-user or some other terminology 
that makes this clear (and avoids debate)

Regards
Lars

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

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 4879 bytes --]

On 05/06/2014 13:47, Artem Mygaiev wrote:
>>>> QNX and other OSes
>>>> will have licenses that are required by corresponding regulations, some
>>>> may be not open nevertheless we tend to make all parts of the code
>>>> available to the Xen community.
>>> Artem, Andrii: Just to clarify
>>> * Can QNX drivers be built a) on Linux and b) without requiring to
>>> purchase QNX
>>> * Are there any issues with QNX driver headers : in other words, can
>>> these be included under OSI approved licenses ?
>>>
>> I agree this is one interesting bit to know.
> a) yes, there is a QNX Momentics IDE available for Linux
> b) there is an "academic" free license and also 30-day evaluation
It is not clear to me whether this would work. So let me try and clarify 
through a few questions.

Question 1: Can the QNX drivers be built with free and open source 
software only (e.g. GCC)? If the answer is yes, that would solve most of 
the problem. If not, we need to look into other options (in a similar 
way as we needed to do this for 
http://wiki.xenproject.org/wiki/Windows_PV_Drivers_Incubation_Project_Proposal 
- where Visual Studio is necessary for individuals to build and test and 
thus ultimately to contribute to the drivers)

Question 2: Can the QNX drivers be tested with free and open source 
software only or is some code under proprietary license necessary? And 
related we probably need some HW to test stuff on in future also?

IMHO being able to test the QNX drivers, should be a long-term goal of 
the subproject. To do this, the Xen Project may have to purchase a QNX 
license for a test machine and some HW. There are several ways to do this:
* Short term: A vendor could decide to test on behalf of the community. 
We have done this before. But it is not ideal in the long-run.
* Long term: We may need some funds from the AB (or a donation from a 
non-AB vendor) to enable this.
* Long term: it is conceivable that the Xen Project may be counted as 
"Non-Commercial Developers", in which case at least the software for 
future test infrastructure could be obtained for free for the Xen Project.

This does not have to be solved straight away and is IMHO not blocking 
the progress of this subproject proposal. Also, we have found a way to 
address this for 
http://wiki.xenproject.org/wiki/Windows_PV_Drivers_Incubation_Project_Proposal

@Artem: Any guidance would be helpful

Note 3: As for a nice development environment such as an IDE: it is IMHO 
acceptable for an IDE to be available under a commercial license, as 
long as an FOSS alternative (e.g. GCC, GDB, ...) is available.

I did check http://www.qnx.org.uk/legal/licensing/non_commercial.html 
which seems to imply that there is a free license for "Non-Commercial 
Developers". The term seems "Non-Commercial Developers" to be tied to 
individuals not working for a commercial end-purpose, which is likely 
good enough. But I have not checked the detailed terms.

This document also seems to have some provision for open source projects 
("non-commercial group projects") - although the terminology is not 
clear and not specific. So I am not sure whether we would count as a 
"non-commercial group project" and whether say a Linux Foundation 
Collaborative project would be able to get a development tools for a 
build and test service under the "Non-Commercial Developers" clause for 
free.

@Artem: Any guidance would be helpful

Question 4: I tripped over 
http://www.qnx.org.uk/legal/licensing/crm.html which raises some 
questions related to QNX licenses and what license we would host QNX 
drivers under. I believe - I will need to check this with the Linux 
Foundation - that as a Collaborative Project we can only host code under 
OSI approved licenses. So we would need to find a compatible OSI 
approved license for the QNX drivers. There also seems to be a note that 
some QNX software is available under Apache licenses (see 
http://www.qnx.org.uk/legal/licensing/open_source.html). I guess what 
this comes down to is whether QNX would allow us to make available a QNX 
BSP for Xen Project software under an OSI approved license (e.g. Apache 
2.0). There is a statement in 
http://www.qnx.org.uk/legal/licensing/open_source.html which says "QSS 
[QNX Software Systems] has begun publishing QNX board support package 
(BSP) software under the Apache License, Version 2.0 (Apache 2.0). 
Members of the QNX developer community are encouraged to use their 
Momentics Tools to create BSPs to allow the QNX RTOS to run on a wider 
variety of hardware platforms [without stating that publication under 
Apache 2 is encouraged - but it sort of implies it]". This implies that 
maybe we are OK, but it needs checking.

@Artem, this is probably something you will need to follow up on and 
provide us with some more clarity. This would potentially be a blocking 
issue for the proposal.

Regards
Lars

[-- Attachment #1.2: Type: text/html, Size: 7433 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Automotive PV drivers project request

[Roger Pau Monné]

On 04/06/14 15:04, Artem Mygaiev wrote:
> As a part of effort on bringing Xen into Automotive (and thus Embedded)
> space, we are working on a set of PV drivers needed to share
> peripherals between domains.
>  * PV audio - new driver using ALSA
>  * PV USB - based on old existing PV USB solution
>  * PV framebuffer - modifications and improvements for existing FB
>  * PV events - new driver for sharing HIDs across domains (touchscreen,
>    keyb, etc.)
> This list is not final, other things are to be added later on. Each
> driver consists, obviously, of frontend and backend which may be
> implemented for different OSes. So far only Linux is supported, QNX is
> wip, ArcCore or similar being considered. Due to this, each driver has
> following structure (sample):
> /pv_audio
>   /linux-alsa-be
>   /linux-fe
>   /qnx-be
>   /qnx-fe
> Linux kernel code is developed under GPLv2 license, userspace
> components like some backends are under Apache 2 license, so can be
> integrated into software with commercial licenses. QNX and other OSes
> will have licenses that are required by corresponding regulations, some
> may be not open nevertheless we tend to make all parts of the code
> available to the Xen community.

Hello,

Most of the Xen PV frontends/backends inside of the Linux kernel are 
under a dual-license like the following (this one is from blkfront):

 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License version 2
 * as published by the Free Software Foundation; or, when distributed
 * separately from the Linux kernel or incorporated into other
 * software packages, subject to the following license:
 *
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this source file (the "Software"), to deal in the Software without
 * restriction, including without limitation the rights to use, copy, modify,
 * merge, publish, distribute, sublicense, and/or sell copies of the Software,
 * and to permit persons to whom the Software is furnished to do so, subject to
 * the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
 * IN THE SOFTWARE.

Which allows them to be imported/shared with other OSes. Could you 
consider releasing the Linux drivers under this kind of license?

Thanks, Roger.

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

[Lars Kurth]

 > Which allows them to be imported/shared with other OSes. Could you 
consider
 > releasing the Linux drivers under this kind of license?

@Roger: Can you explain why this is a good idea? Apart from consitency
I think I know, but am not 100% sure. I suppose there are benefits for 
the likes of MiniOS, BSD, ...

Lars

On 04/06/2014 15:36, Roger Pau Monné wrote:
> On 04/06/14 15:04, Artem Mygaiev wrote:
>> As a part of effort on bringing Xen into Automotive (and thus Embedded)
>> space, we are working on a set of PV drivers needed to share
>> peripherals between domains.
>>   * PV audio - new driver using ALSA
>>   * PV USB - based on old existing PV USB solution
>>   * PV framebuffer - modifications and improvements for existing FB
>>   * PV events - new driver for sharing HIDs across domains (touchscreen,
>>     keyb, etc.)
>> This list is not final, other things are to be added later on. Each
>> driver consists, obviously, of frontend and backend which may be
>> implemented for different OSes. So far only Linux is supported, QNX is
>> wip, ArcCore or similar being considered. Due to this, each driver has
>> following structure (sample):
>> /pv_audio
>>    /linux-alsa-be
>>    /linux-fe
>>    /qnx-be
>>    /qnx-fe
>> Linux kernel code is developed under GPLv2 license, userspace
>> components like some backends are under Apache 2 license, so can be
>> integrated into software with commercial licenses. QNX and other OSes
>> will have licenses that are required by corresponding regulations, some
>> may be not open nevertheless we tend to make all parts of the code
>> available to the Xen community.
> Hello,
>
> Most of the Xen PV frontends/backends inside of the Linux kernel are
> under a dual-license like the following (this one is from blkfront):
>
>   * This program is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU General Public License version 2
>   * as published by the Free Software Foundation; or, when distributed
>   * separately from the Linux kernel or incorporated into other
>   * software packages, subject to the following license:
>   *
>   * Permission is hereby granted, free of charge, to any person obtaining a copy
>   * of this source file (the "Software"), to deal in the Software without
>   * restriction, including without limitation the rights to use, copy, modify,
>   * merge, publish, distribute, sublicense, and/or sell copies of the Software,
>   * and to permit persons to whom the Software is furnished to do so, subject to
>   * the following conditions:
>   *
>   * The above copyright notice and this permission notice shall be included in
>   * all copies or substantial portions of the Software.
>   *
>   * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>   * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>   * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
>   * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>   * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>   * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
>   * IN THE SOFTWARE.
>
> Which allows them to be imported/shared with other OSes. Could you
> consider releasing the Linux drivers under this kind of license?
>
> Thanks, Roger.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[Roger Pau Monné]

On 04/06/14 17:21, Lars Kurth wrote:
>> Which allows them to be imported/shared with other OSes. Could you
> consider
>> releasing the Linux drivers under this kind of license?
> 
> @Roger: Can you explain why this is a good idea? Apart from consitency
> I think I know, but am not 100% sure. I suppose there are benefits for
> the likes of MiniOS, BSD, ...

So that those drivers can be imported into other OSes which are not
under the GPL. As you say, I was mainly thinking about MiniOS and BSDs.

Roger.

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

[Artem Mygaiev]

Roger, Lars,
If there's a good reason (and I think there is) to use the
dual-license, we'll go for it
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


On Wed, Jun 4, 2014 at 4:34 PM, Roger Pau Monné <roger.pau@citrix.com> wrote:
> On 04/06/14 17:21, Lars Kurth wrote:
>>> Which allows them to be imported/shared with other OSes. Could you
>> consider
>>> releasing the Linux drivers under this kind of license?
>>
>> @Roger: Can you explain why this is a good idea? Apart from consitency
>> I think I know, but am not 100% sure. I suppose there are benefits for
>> the likes of MiniOS, BSD, ...
>
> So that those drivers can be imported into other OSes which are not
> under the GPL. As you say, I was mainly thinking about MiniOS and BSDs.
>
> Roger.
>

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

Re: Automotive PV drivers project request

[David Vrabel]

On 04/06/14 14:04, Artem Mygaiev wrote:
> As a part of effort on bringing Xen into Automotive (and thus Embedded)
> space, we are working on a set of PV drivers needed to share
> peripherals between domains.
>  * PV audio - new driver using ALSA
>  * PV USB - based on old existing PV USB solution
>  * PV framebuffer - modifications and improvements for existing FB
>  * PV events - new driver for sharing HIDs across domains (touchscreen,
>    keyb, etc.)
> This list is not final, other things are to be added later on. Each
> driver consists, obviously, of frontend and backend which may be
> implemented for different OSes. So far only Linux is supported, QNX is
> wip, ArcCore or similar being considered. Due to this, each driver has
> following structure (sample):
> /pv_audio
>   /linux-alsa-be
>   /linux-fe
>   /qnx-be
>   /qnx-fe
> Linux kernel code is developed under GPLv2 license, userspace
> components like some backends are under Apache 2 license, so can be
> integrated into software with commercial licenses. QNX and other OSes
> will have licenses that are required by corresponding regulations, some
> may be not open nevertheless we tend to make all parts of the code
> available to the Xen community.

I don't want to see Linux drivers languishing in a sub-project -- they
should all be merged into Linux proper.

David

Re: Automotive PV drivers project request

[Artem Mygaiev]

David, agree on all kernel drivers but what about userspace backends
and other OSes?
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


On Thu, Jun 5, 2014 at 2:17 PM, David Vrabel <david.vrabel@citrix.com> wrote:
> On 04/06/14 14:04, Artem Mygaiev wrote:
>> As a part of effort on bringing Xen into Automotive (and thus Embedded)
>> space, we are working on a set of PV drivers needed to share
>> peripherals between domains.
>>  * PV audio - new driver using ALSA
>>  * PV USB - based on old existing PV USB solution
>>  * PV framebuffer - modifications and improvements for existing FB
>>  * PV events - new driver for sharing HIDs across domains (touchscreen,
>>    keyb, etc.)
>> This list is not final, other things are to be added later on. Each
>> driver consists, obviously, of frontend and backend which may be
>> implemented for different OSes. So far only Linux is supported, QNX is
>> wip, ArcCore or similar being considered. Due to this, each driver has
>> following structure (sample):
>> /pv_audio
>>   /linux-alsa-be
>>   /linux-fe
>>   /qnx-be
>>   /qnx-fe
>> Linux kernel code is developed under GPLv2 license, userspace
>> components like some backends are under Apache 2 license, so can be
>> integrated into software with commercial licenses. QNX and other OSes
>> will have licenses that are required by corresponding regulations, some
>> may be not open nevertheless we tend to make all parts of the code
>> available to the Xen community.
>
> I don't want to see Linux drivers languishing in a sub-project -- they
> should all be merged into Linux proper.
>
> David

Re: Automotive PV drivers project request

[David Vrabel]

On 05/06/14 14:22, Artem Mygaiev wrote:
> David, agree on all kernel drivers but what about userspace backends
> and other OSes?

I don't have an opinion on user space drivers.  I would suggest that
userspace backends live with the existing ones in qemu.

Are userspace frontends useful?  Isn't a kernel driver required for
proper access control?

David

Re: Automotive PV drivers project request

[Lars Kurth]

On 10/06/2014 13:38, David Vrabel wrote:
> On 05/06/14 14:22, Artem Mygaiev wrote:
>> David, agree on all kernel drivers but what about userspace backends
>> and other OSes?
> I don't have an opinion on user space drivers.  I would suggest that
> userspace backends live with the existing ones in qemu.
>
> Are userspace frontends useful?  Isn't a kernel driver required for
> proper access control?
David,

I believe the answer is in 
http://wiki.xenproject.org/wiki/XPDS13_BoF_Notes_:_Seeding_an_Android_and_Embedded_ecosystem#Missing_Pieces_for_a_complete_Android_system_on_top_of_Xen

As far as I understand, Android requires functionality to be made 
available via userspace drivers. These would sit on top of the kernel 
drivers.

Lars

Re: Automotive PV drivers project request

[Artem Mygaiev]

[-- Attachment #1.1: Type: text/plain, Size: 1451 bytes --]

David, Lars,

Indeed, userspace drivers in Android essentially are set of so libraries
for libhardware which provides some sort of a HAL to kenel drivers. In
order to simplify things we can avoid kernel drivers in Andorid and go
straight to userspace.

I do not think that it is correct to mix PV drivers backends with QEMU, we
do not do full emulation in most cases, just PVHVM

Artem Mygaiev | AVP - Delivery
GlobalLogic
P +380.44.4929695 ext.2023 M +380.67.9211131 S rosenkrantzguildenstern
www.globallogic.com
<http://www.globallogic.com/>
http://www.globallogic.com/email_disclaimer.txt


On Tue, Jun 10, 2014 at 5:09 PM, Lars Kurth <lars.kurth@xen.org> wrote:

> On 10/06/2014 13:38, David Vrabel wrote:
>
>> On 05/06/14 14:22, Artem Mygaiev wrote:
>>
>>> David, agree on all kernel drivers but what about userspace backends
>>> and other OSes?
>>>
>> I don't have an opinion on user space drivers.  I would suggest that
>> userspace backends live with the existing ones in qemu.
>>
>> Are userspace frontends useful?  Isn't a kernel driver required for
>> proper access control?
>>
> David,
>
> I believe the answer is in http://wiki.xenproject.org/
> wiki/XPDS13_BoF_Notes_:_Seeding_an_Android_and_Embedded_ecosystem#Missing_
> Pieces_for_a_complete_Android_system_on_top_of_Xen
>
> As far as I understand, Android requires functionality to be made
> available via userspace drivers. These would sit on top of the kernel
> drivers.
>
> Lars
>

[-- Attachment #1.2: Type: text/html, Size: 4597 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Automotive PV drivers project request

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

On Tue, 10 Jun 2014, Artem Mygaiev wrote:
> David, Lars,
> 
> Indeed, userspace drivers in Android essentially are set of so libraries for libhardware which provides some sort of a HAL
> to kenel drivers. In order to simplify things we can avoid kernel drivers in Andorid and go straight to userspace.
> 
> I do not think that it is correct to mix PV drivers backends with QEMU, we do not do full emulation in most cases, just
> PVHVM

You don't need to do any emulation whatsoever in order to run the PV
backends in QEMU.  You can simply execute QEMU to provide only the PV
backends and nothing else by passing -M xenpv.

In fact we use QEMU as userspace PV backend provider for x86 PV guests,
that do not require any emulation on the hypervisor side at all.

Having the PV backends in QEMU gives you a common framework to write PV
drivers and access xenstore (see hw/xen/xen_backend.c).


> 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
> 
> 
> On Tue, Jun 10, 2014 at 5:09 PM, Lars Kurth <lars.kurth@xen.org> wrote:
>       On 10/06/2014 13:38, David Vrabel wrote:
>             On 05/06/14 14:22, Artem Mygaiev wrote:
>                   David, agree on all kernel drivers but what about userspace backends
>                   and other OSes?
> 
>             I don't have an opinion on user space drivers.  I would suggest that
>             userspace backends live with the existing ones in qemu.
> 
>             Are userspace frontends useful?  Isn't a kernel driver required for
>             proper access control?
> 
> David,
> 
> I believe the answer is inhttp://wiki.xenproject.org/wiki/XPDS13_BoF_Notes_:_Seeding_an_Android_and_Embedded_ecosystem#Missing_Pieces_for_a_complet
> e_Android_system_on_top_of_Xen
> 
> As far as I understand, Android requires functionality to be made available via userspace drivers. These would sit
> on top of the kernel drivers.
> 
> Lars
> 
> 
> 
> 

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Automotive PV drivers project request (need more input)

[Lars Kurth]

Hi all,

I collated this thread into 
http://wiki.xen.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal 


This raises a number of extra questions besides the licensing questions 
I raised to Artem earlier.

Q1: should we have separate git repos per OS, e.g.
   git://xenbits.xen.org/pvdrivers/xen-linux-user-drivers.git
   git://xenbits.xen.org/pvdrivers/xen-qnx-drivers.git

instead of
   git://xenbits.xen.org/pvdrivers/pvdrivers.git

This sounds more user friendly and scalable

Q2: should 
http://wiki.xen.org/wiki/Windows_PV_Drivers_Incubation_Project_Proposal 
& 
http://wiki.xen.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal 
share infrastructure (e.g. lists, web portal, 
git://xenbits.xen.org/pvdrivers/) or even be merged

There is no clear-cut answer.

Arguments against merging:
* Forces people with very different interests into one subproject (aka 
creates unnecessary noise)
* Dilutes Project Leadership

Arguments for merging:
* Critical mass for graduation is more easily reached (but may be fake)
* Increases chances of building a sustainable community

If we don't merge, we should not use the generic label "pvdrivers" for 
xenbits and mailing lists for this proposal, but use something more 
specific. We also need a label for the Windows PV driver project.

Best Regards
Lars

Re: Automotive PV drivers project request (need more input)

[Stefano Stabellini]

On Wed, 11 Jun 2014, Lars Kurth wrote:
> Hi all,
> 
> I collated this thread into
> http://wiki.xen.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal 
> 
> This raises a number of extra questions besides the licensing questions I
> raised to Artem earlier.
> 
> Q1: should we have separate git repos per OS, e.g.
>   git://xenbits.xen.org/pvdrivers/xen-linux-user-drivers.git
>   git://xenbits.xen.org/pvdrivers/xen-qnx-drivers.git
> 
> instead of
>   git://xenbits.xen.org/pvdrivers/pvdrivers.git
> 
> This sounds more user friendly and scalable


Sounds like a good idea to me


> Q2: should
> http://wiki.xen.org/wiki/Windows_PV_Drivers_Incubation_Project_Proposal &
> http://wiki.xen.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal
> share infrastructure (e.g. lists, web portal,
> git://xenbits.xen.org/pvdrivers/) or even be merged
> 
> There is no clear-cut answer.
> 
> Arguments against merging:
> * Forces people with very different interests into one subproject (aka creates
> unnecessary noise)
> * Dilutes Project Leadership
> 
> Arguments for merging:
> * Critical mass for graduation is more easily reached (but may be fake)
> * Increases chances of building a sustainable community
> 
> If we don't merge, we should not use the generic label "pvdrivers" for xenbits
> and mailing lists for this proposal, but use something more specific. We also
> need a label for the Windows PV driver project.

I think that using the generic name "pvdrivers" is a good idea and would
encourage other people with different pvdrivers for other OSes to join
the effort. So maybe we do need to unify the Windows PV drivers project.

Re: Automotive PV drivers project request (need more input)

[Paul Durrant]

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: 12 June 2014 10:34
> To: Lars Kurth
> Cc: Stefano Stabellini; Artem Mygaiev; David Vrabel; xen-
> devel@lists.xen.org; Andrii Tseglytskyi; Ian Jackson; Paul Durrant
> Subject: Re: [Xen-devel] Automotive PV drivers project request (need more
> input)
> 
> On Wed, 11 Jun 2014, Lars Kurth wrote:
> > Hi all,
> >
> > I collated this thread into
> >
> http://wiki.xen.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_
> Proposal
> >
> > This raises a number of extra questions besides the licensing questions I
> > raised to Artem earlier.
> >
> > Q1: should we have separate git repos per OS, e.g.
> >   git://xenbits.xen.org/pvdrivers/xen-linux-user-drivers.git
> >   git://xenbits.xen.org/pvdrivers/xen-qnx-drivers.git
> >
> > instead of
> >   git://xenbits.xen.org/pvdrivers/pvdrivers.git
> >
> > This sounds more user friendly and scalable
> 
> 
> Sounds like a good idea to me
> 
> 
> > Q2: should
> >
> http://wiki.xen.org/wiki/Windows_PV_Drivers_Incubation_Project_Proposa
> l &
> >
> http://wiki.xen.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_
> Proposal
> > share infrastructure (e.g. lists, web portal,
> > git://xenbits.xen.org/pvdrivers/) or even be merged
> >
> > There is no clear-cut answer.
> >
> > Arguments against merging:
> > * Forces people with very different interests into one subproject (aka
> creates
> > unnecessary noise)
> > * Dilutes Project Leadership
> >
> > Arguments for merging:
> > * Critical mass for graduation is more easily reached (but may be fake)
> > * Increases chances of building a sustainable community
> >
> > If we don't merge, we should not use the generic label "pvdrivers" for
> xenbits
> > and mailing lists for this proposal, but use something more specific. We also
> > need a label for the Windows PV driver project.
> 
> I think that using the generic name "pvdrivers" is a good idea and would
> encourage other people with different pvdrivers for other OSes to join
> the effort. So maybe we do need to unify the Windows PV drivers project.

IMO, Windows PV drivers are a sufficiently distinct codebase, and will almost certainly remain so, that the sub-project should be independent. There's already a long history of (different sets of) Windows PV drivers for Xen and a loose community surrounding them, which the project is aiming to unify around a existent common codebase. I think it would very much confuse things to try to combine these sub-projects.

  Paul