Mailing List Archive

On 1 Jul 2014, at 12:53, Lars Kurth <lars.kurth@xen.org> wrote:
> Hi all,
>
> the "Embedded and Automotive PV Drivers Sub-Project Proposal" (see http://wiki.xenproject.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal) is now open for community review. Please provide feedback by replying to this thread or using the Comment feature (see http://wiki.xenproject.org/wiki/Template:Comment) using "{{comment|~~~~}} My comment" on the relevant section of the wiki page.

Looks great! A few comments:

- "pv_fb driver provide audio driver back- " => audio should be "framebuffer"

- Several of the drivers overlap with existing front/back drivers (for example, the pv_usb one). Is there a plan to merge these, or at least document the differences between QNX and the Linux/BSD versions of the relevant ring protocols?

- Not sure why the pv_gpu drivers has a "lnx-alsa-be/" entry in the drivers. Might be a c&p error.

cheers,
ANil

>
> I extended the deadline by a few days, to account for the 4th of July holidays/vacation in the USA
>
> Best Regards
> Lars
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>


_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

Anil,
thank you for the feedback. I will need to let Artem and Alex answer
your questions. I merely copied and pasted these from a document
Regards
Lars

On 01/07/2014 14:56, Anil Madhavapeddy wrote:
> On 1 Jul 2014, at 12:53, Lars Kurth <lars.kurth@xen.org> wrote:
>> Hi all,
>>
>> the "Embedded and Automotive PV Drivers Sub-Project Proposal" (see http://wiki.xenproject.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal) is now open for community review. Please provide feedback by replying to this thread or using the Comment feature (see http://wiki.xenproject.org/wiki/Template:Comment) using "{{comment|~~~~}} My comment" on the relevant section of the wiki page.
> Looks great! A few comments:
>
> - "pv_fb driver provide audio driver back- " => audio should be "framebuffer"
>
> - Several of the drivers overlap with existing front/back drivers (for example, the pv_usb one). Is there a plan to merge these, or at least document the differences between QNX and the Linux/BSD versions of the relevant ring protocols?
>
> - Not sure why the pv_gpu drivers has a "lnx-alsa-be/" entry in the drivers. Might be a c&p error.
>
> cheers,
> ANil
>
>> I extended the deadline by a few days, to account for the 4th of July holidays/vacation in the USA
>>
>> Best Regards
>> Lars
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>


_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

On Tue, 2014-07-01 at 10:53 +0100, Lars Kurth wrote:
> Hi all,
>
> the "Embedded and Automotive PV Drivers Sub-Project Proposal" (see
> http://wiki.xenproject.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal)
> is now open for community review. Please provide feedback by replying to
> this thread

I think you should avoid the word "staging" entirely in this document.

A staging tree in Xen terminology is something completely different to
how you use it here: it's the tree where the committers push things which
serves as the input to our automated test. How about "development" tree?
Or just avoid them altogether by using the individual developer's own
trees and the lists.

WRT xen-devel being busy and the subproject's own lists, it might be
wise to have upstream exposure from early on, which would imply ccing
xen-devel/lkml etc in addition to the subproject list. Otherwise you get
into the issue where the subproject has accepted something (perhaps into
a "staging" tree) but when it gets sent upstream it requires major
reworking (and the developer is long gone, etc etc). Whether that needs
to be part of the charter though I don't know.

More minor thoughts:

"it is likely and desirable that the project may be useful for other"

I'm not sure if this sentence has the end missing or if you
intended other to be "others".

"Part of the reason for this is that some of the hardware to test is
also not yet available to open source communities."

This is not (and should not be) a barrier to sending patches to
the right place. We have reviewed and accepted plenty of patches
for which we have no access to the h/w.

"To build these drivers, the QNX GNU libc variant is used (licensed
under GPL)."

Not LGPL? QNX using GPL for it's libc seems like an odd choice
for them, since it requires anything linking against it to be
GPL compatible. I suspect this a typo.

"Must have OSI approved licenses that are required to link with and
usage the drivers within the native OS."

I can't parse this sentence. I think s/usage/use might be what
was meant but I'm not sure.

"upstreamns"

Typo

WRT graduation -- can we include a requirement that any "staging" trees
have been retired (e.g. merged upstream or otherwise obsolete).

Ian.


_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

On 09/07/2014 11:42, Ian Campbell wrote:
> On Tue, 2014-07-01 at 10:53 +0100, Lars Kurth wrote:
>> Hi all,
>>
>> the "Embedded and Automotive PV Drivers Sub-Project Proposal" (see
>> http://wiki.xenproject.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal)
>> is now open for community review. Please provide feedback by replying to
>> this thread
> I think you should avoid the word "staging" entirely in this document.
>
> A staging tree in Xen terminology is something completely different to
> how you use it here: it's the tree where the committers push things which
> serves as the input to our automated test. How about "development" tree?
> Or just avoid them altogether by using the individual developer's own
> trees and the lists.
Either approach works for me.
I replaced "staging" with "development" for now and made it optional. We
can leave a final decision open. It shouldn't block the proposal

Andrii requested a personal repo, which has not been created yet, but
Ian Jackson is doing this as we speak

>
> WRT xen-devel being busy and the subproject's own lists, it might be
> wise to have upstream exposure from early on, which would imply ccing
> xen-devel/lkml etc in addition to the subproject list. Otherwise you get
> into the issue where the subproject has accepted something (perhaps into
> a "staging" tree) but when it gets sent upstream it requires major
> reworking (and the developer is long gone, etc etc). Whether that needs
> to be part of the charter though I don't know.
Agreed. CCing other relevant lists (aka xen-devel/lkml) is common
practice and we should just continue doing this. I can stated this in
the proposal.

>
> More minor thoughts:
>
> "it is likely and desirable that the project may be useful for other"
>
> I'm not sure if this sentence has the end missing or if you
> intended other to be "others".
Should read "other use-cases". (fixed)
>
> "Part of the reason for this is that some of the hardware to test is
> also not yet available to open source communities."
>
> This is not (and should not be) a barrier to sending patches to
> the right place. We have reviewed and accepted plenty of patches
> for which we have no access to the h/w.
You are correct. I deleted this sentence as it doesn't add anything
>
> "To build these drivers, the QNX GNU libc variant is used (licensed
> under GPL)."
>
> Not LGPL? QNX using GPL for it's libc seems like an odd choice
> for them, since it requires anything linking against it to be
> GPL compatible. I suspect this a typo.
Corrected
>
> "Must have OSI approved licenses that are required to link with and
> usage the drivers within the native OS."
>
> I can't parse this sentence. I think s/usage/use might be what
> was meant but I'm not sure.
Fixed. Meant "use"
>
> "upstreamns"
>
> Typo
Fixed
>
> WRT graduation -- can we include a requirement that any "staging" trees
> have been retired (e.g. merged upstream or otherwise obsolete).
Done
>
> Ian.
>

On Wed, 2014-07-09 at 12:28 +0100, Lars Kurth wrote:

> >
> > "To build these drivers, the QNX GNU libc variant is used (licensed
> > under GPL)."
> >
> > Not LGPL? QNX using GPL for it's libc seems like an odd choice
> > for them, since it requires anything linking against it to be
> > GPL compatible. I suspect this a typo.
> Corrected

Just to be clear; I've no idea what license the QNX libc is under, it
could be GPL for all I know, I was just querying it because it surprised
me.

(Just want to be sure you didn't assume I know it was LGPL or something)

Ian.


_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

On 09/07/2014 12:46, Ian Campbell wrote:
> On Wed, 2014-07-09 at 12:28 +0100, Lars Kurth wrote:
>
>>> "To build these drivers, the QNX GNU libc variant is used (licensed
>>> under GPL)."
>>>
>>> Not LGPL? QNX using GPL for it's libc seems like an odd choice
>>> for them, since it requires anything linking against it to be
>>> GPL compatible. I suspect this a typo.
>> Corrected
> Just to be clear; I've no idea what license the QNX libc is under, it
> could be GPL for all I know, I was just querying it because it surprised
> me.
>
> (Just want to be sure you didn't assume I know it was LGPL or something)
I did go back and checked it. I tripped over it, as this was thrown into
a collection with compilers. It needed drilling a level deeper down
Lars

_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api