- Tsc - lists.openampproject.org

by Nathalie Chan King Choy

Hi all, The notes from the previous call can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2021#20210615 Action items from previous call: * Jeff to send Nathalie the Siemens logo [DONE] * Nathalie: Check w/ Stefano if anything related to DT could make sense to present [DONE] * Tomas, Nathalie: organize a kick-off meeting for end-to-end example project * Tomas: Call for interest to see if can harmonize virtio (both leadership, resources). * Loic & Stefano to discuss virtio & Stratos alignment further. * Nathalie: Schedule next OpenAMP TSC for end of July [DONE] For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community Wednesday, July 21, 2021 9:00 AM | (UTC-07:00) Pacific Time (US & Canada) | 1 hr Join meeting<https://xilinx.webex.com/xilinx/j.php?MTID=mec962a2ed990ef1c35df9ea8b56d30e6> More ways to join: Join from the meeting link https://xilinx.webex.com/xilinx/j.php?MTID=mec962a2ed990ef1c35df9ea8b56d30e6 Join by meeting number Meeting number (access code): 145 261 2375 Meeting password: QMu2V3qUE$2 Join by phone +1-415-655-0001 US Toll 1-844-621-3956 United States Toll Free Global call-in numbers<https://xilinx.webex.com/xilinx/globalcallin.php?MTID=m36ec83ced825b74c9ab6…> | Toll-free calling restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf> Need help? Go to https://help.webex.com

4 years, 11 months

1
0
0 0

2021-06-15 OpenAMP TSC notes and action items

by Nathalie Chan King Choy

Hi all, Notes and link to the recording for the June OpenAMP TSC call are available at: https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2021#20210615 Please download the recording in the next few weeks, if you need to get caught up. Not sure how long before Webex auto-deletes. Action items: * Jeff to send Nathalie the Siemens logo [DONE] * Nathalie: Check w/ Stefano if anything related to DT could make sense to present for LVC21F * Tomas, Nathalie: organize a kick-off meeting for end-to-end example project * Tomas: Call for interest to see if can harmonize virtio (both leadership, resources). * Loic & Stefano to discuss virtio & Stratos alignment further. * Nathalie: Schedule next OpenAMP TSC for end of July Thanks & regards, Nathalie

4 years, 11 months

1
0
0 0

my slides from TSC meeting May 26th

by Koning, Maarten

Better late than never, here is my slide from May 26th TSC meeting. \Maarten [Graphical user interface, text, application Description automatically generated]

4 years, 12 months

1
0
0 0

Calling for agenda items: OpenAMP TSC - June

by Nathalie Chan King Choy

Hi all, Here are the agenda items that I have so far (left over from the May agenda): * Tomas, Kumar: Heterogeneous end-to-end example * Nathalie: LVC21F CFP - Does OpenAMP Project have topics to submit? * Maarten, Jeff, Tomas: Inclusive terms * Tomas: OpenAMP resourcing needs for various upcoming initiatives Please let me know if you have additional agenda items. Thanks & regards, Nathalie -----Original Appointment----- From: Nathalie Chan King Choy Sent: Wednesday, June 2, 2021 9:55 AM To: Nathalie Chan King Choy; tsc(a)lists.openampproject.org Cc: Felix Burton; nathalie-ckc(a)kestrel-omnitech.com; Bruce Ashfield; Glaropoulos, Ioannis; Tomas Evensen Subject: OpenAMP TSC - June When: Tuesday, June 15, 2021 10:00 AM-11:00 AM (UTC-08:00) Pacific Time (US & Canada). Where: webex Hi all, The notes from the previous call (May 26) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2021#20210526 Action items from May 26 call: * Stefano & Nathalie: set up next System DT call (aim for mid-June) [DONE] * Stefano: Send out slide from today [DONE] * Maarten: Send out slide from today * Maarten: Schedule meeting on the Zephyr work * Tomas, Bill: discuss resource plan in another meeting soon w/ Kumar (this week) [DONE] * Nathalie: Set up follow-up TSC call in a couple weeks [DONE] For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community Tuesday, June 15, 2021 10:00 AM | (UTC-07:00) Pacific Time (US & Canada) | 1 hr Join meeting<https://xilinx.webex.com/xilinx/j.php?MTID=m0227589b5303bd0db634adfc516f62fc> More ways to join: Join from the meeting link https://xilinx.webex.com/xilinx/j.php?MTID=m0227589b5303bd0db634adfc516f62fc Join by meeting number Meeting number (access code): 145 109 5706 Meeting password: QCmwsq3d@77 Join by phone +1-415-655-0001 US Toll 1-844-621-3956 United States Toll Free Global call-in numbers<https://xilinx.webex.com/xilinx/globalcallin.php?MTID=m4c9051a79e171862d34c…> | Toll-free calling restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf> Need help? Go to https://help.webex.com

5 years

1
0
0 0

OpenAMP TSC - June

by Nathalie Chan King Choy

Hi all, The notes from the previous call (May 26) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2021#20210526 Action items from May 26 call: * Stefano & Nathalie: set up next System DT call (aim for mid-June) * Stefano: Send out slide from today [DONE] * Maarten: Send out slide from today * Maarten: Schedule meeting on the Zephyr work * Tomas, Bill: discuss resource plan in another meeting soon w/ Kumar (this week) [DONE] * Nathalie: Set up follow-up TSC call in a couple weeks [DONE] For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community Tuesday, June 15, 2021 10:00 AM | (UTC-07:00) Pacific Time (US & Canada) | 1 hr Join meeting<https://xilinx.webex.com/xilinx/j.php?MTID=m0227589b5303bd0db634adfc516f62fc> More ways to join: Join from the meeting link https://xilinx.webex.com/xilinx/j.php?MTID=m0227589b5303bd0db634adfc516f62fc Join by meeting number Meeting number (access code): 145 109 5706 Meeting password: QCmwsq3d@77 Join by phone +1-415-655-0001 US Toll 1-844-621-3956 United States Toll Free Global call-in numbers<https://xilinx.webex.com/xilinx/globalcallin.php?MTID=m4c9051a79e171862d34c…> | Toll-free calling restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf> Need help? Go to https://help.webex.com

5 years

1
0
0 0

System Device Tree update slides

by Stefano Stabellini

Hi all, I am attaching the slide for the System Device Tree update I showed during the OpenAMP TSC meeting on Wednesday this week. Cheers, Stefano

5 years

1
0
0 0

2021-05-26 - OpenAMP TSC meeting notes and action items

by Nathalie Chan King Choy

Hi all, Notes and link to the recording are available at: https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2021#20210526 Please download the recording in the next few weeks, if you need to get caught up. Not sure how long before Webex auto-deletes. Action items * Stefano & Nathalie: set up next System DT call (aim for mid-June) * Stefano: Send out slide from today * Maarten: Send out slide from today * Maarten: Schedule meeting on the Zephyr work * Tomas, Bill: discuss resource plan in another meeting soon w/ Kumar (this week) * Nathalie: Set up follow-up TSC call in a couple weeks Thanks & regards, Nathalie

5 years

1
0
0 0

Re: [OA-Tsc] Calling for agenda items: OpenAMP TSC - May 2021

by Bill Mills

All, openamp-rp status and roadmap: Status: * Keeping the lights on * Released new open-amp and libmetal lib versions * this opened the flood gate of pull requests, see below * Kernel patch activity is slowing down as much of the high priority backlog has been worked through * Xilinx R5 is still out standing Big changes purposed: * Namespace message enhancement * know when a client connects and disconnects * if we are to make a change I think we should cover more needs than just this so I am working on a NS 2.0 proposal * Resource table enhancements * Arnaud is driving but finds that current model needs to documented first * message size configuration at startup time Plans for next 6 months * Spec document * start by moving Arnaud's resource table doc to sphinx / rst * Infrastructure for documentation in general * Bill is looking at EBBR for spec focus, and Zephyr and Yocto Project for whole project https://arm-software.github.io/ebbr/ https://docs.yoctoproject.org/ https://docs.zephyrproject.org/latest/ * CI advances * at least run linux user space to user space tests * Hopefully QEMU based test also (by any mean necessary) * Progress on big changes above * Demo w/ multiple virtques: * rpmsg and virtio i2c for example * Our part of whole openamp demo * SysDT, openamp-rp & openamp app srvs Bill On 5/25/21 7:38 PM, Nathalie Chan King Choy via Tsc wrote: > Wednesday’s agenda: > > * 1 min: Maintainer news > * 10-15 min: Tomas, Kumar: Heterogeneous end-to-end example > * 3 x 5 min: Stefano, Bill, Maarten: working group updates > * 5 min: Nathalie: LVC21F CFP - Does OpenAMP Project have topics to > submit? > * 10 min: Maarten, Jeff, Tomas: Inclusive terms > * 10 min: Tomas: OpenAMP resourcing needs for various upcoming initiatives > > *From:* Tsc <tsc-bounces(a)lists.openampproject.org> *On Behalf Of > *Nathalie Chan King Choy via Tsc > *Sent:* Wednesday, May 19, 2021 3:51 PM > *To:* tsc(a)lists.openampproject.org > *Subject:* [OA-Tsc] Calling for agenda items: OpenAMP TSC - May 2021 > > Hi all, > > Please send your requests for agenda items for the 5/26 OpenAMP TSC > call. Here’s what I have so far: > > * Tomas: End-to-end example > * Maarten, Jeff, Tomas: Inclusive terms > > * Nathalie: Are there any OpenAMP topics that would make sense to > submit for the LVC21F CFP? > > Thanks & regards, > > Nathalie > > > -- > Tsc mailing list > Tsc(a)lists.openampproject.org > https://lists.openampproject.org/mailman/listinfo/tsc > -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

5 years

1
0
0 0

Re: [OA-Tsc] Calling for agenda items: OpenAMP TSC - May 2021

by Nathalie Chan King Choy

Wednesday's agenda: * 1 min: Maintainer news * 10-15 min: Tomas, Kumar: Heterogeneous end-to-end example * 3 x 5 min: Stefano, Bill, Maarten: working group updates * 5 min: Nathalie: LVC21F CFP - Does OpenAMP Project have topics to submit? * 10 min: Maarten, Jeff, Tomas: Inclusive terms * 10 min: Tomas: OpenAMP resourcing needs for various upcoming initiatives From: Tsc <tsc-bounces(a)lists.openampproject.org> On Behalf Of Nathalie Chan King Choy via Tsc Sent: Wednesday, May 19, 2021 3:51 PM To: tsc(a)lists.openampproject.org Subject: [OA-Tsc] Calling for agenda items: OpenAMP TSC - May 2021 Hi all, Please send your requests for agenda items for the 5/26 OpenAMP TSC call. Here's what I have so far: * Tomas: End-to-end example * Maarten, Jeff, Tomas: Inclusive terms * Nathalie: Are there any OpenAMP topics that would make sense to submit for the LVC21F CFP? Thanks & regards, Nathalie

5 years

1
0
0 0

Calling for agenda items: OpenAMP TSC - May 2021

by Nathalie Chan King Choy

Hi all, Please send your requests for agenda items for the 5/26 OpenAMP TSC call. Here's what I have so far: * Tomas: End-to-end example * Maarten, Jeff, Tomas: Inclusive terms * Nathalie: Are there any OpenAMP topics that would make sense to submit for the LVC21F CFP? Thanks & regards, Nathalie

5 years

1
0
0 0

OpenAMP TSC - May 2021

by Nathalie Chan King Choy

Hi all, The notes from the previous call (Dec 4) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20201204 For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community Wednesday, May 26, 2021 7:00 AM | (UTC-07:00) Pacific Time (US & Canada) | 1 hr Join meeting<https://xilinx.webex.com/xilinx/j.php?MTID=me95a526b5d4e8d3af7e1a0928cd6a1a8> More ways to join: Join from the meeting link https://xilinx.webex.com/xilinx/j.php?MTID=me95a526b5d4e8d3af7e1a0928cd6a1a8 Join by meeting number Meeting number (access code): 145 273 6316 Meeting password: qFpRsYF*423 Join by phone +1-415-655-0001 US Toll 1-844-621-3956 United States Toll Free Global call-in numbers<https://xilinx.webex.com/xilinx/globalcallin.php?MTID=m7bb0ac6cab454fda872b…> | Toll-free calling restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf> Need help? Go to https://help.webex.com

5 years, 1 month

1
0
0 0

Hypervisorless virtio blog post published

by Nathalie Chan King Choy

Hi App-services working group and OpenAMP TSC, Thanks to Dan for writing up a blog post on the Hypervisorless virtio work done at Wind River. Also, thanks to those who helped review. It is now published on the OpenAMP Project website: https://www.openampproject.org/news/hypervisorless-virtio-blog/ Please spread the word :) Have a wonderful weekend, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community

5 years, 3 months

1
0
0 0

Re: [OA-Tsc] git repos for OpenAMP Appl Svcs WG

by Tomas Evensen

Hi Arnaud, Thanks for checking. You are right that we should have some of formalism when we add new repos. In this case, I think we are fine, since we have discussed this at the board level and in other meetings and we asked Wind River to make this contribution. But just to make sure, I have added the TSC and board lists to the thread. TCS members and board members: Please let us know if there are any concerns with adding kvmtool to the OpenAMP repo. Thanks, Tomas From: Arnaud POULIQUEN <arnaud.pouliquen(a)st.com> Date: Wednesday, February 24, 2021 at 8:39 AM To: Dan Milea <danut.milea(a)windriver.com>, "Ed T. Mooring" <emooring(a)xilinx.com> Cc: "Woolley, Rob" <Rob.Woolley(a)windriver.com>, Bill Mills <bill.mills(a)linaro.org>, Tomas Evensen <tomase(a)xilinx.com>, Nathalie Chan King Choy <nathalie(a)xilinx.com>, "Koning, Maarten" <maarten.koning(a)windriver.com>, "Loic com>" <loic.pallardy(a)st.com> Subject: RE: git repos for OpenAMP Appl Svcs WG CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email. Hi Dan, all, This is the first request to create a new repo under the OpenAMP Github, I don’t think that there is a specific TSC charter defined for that. I wonder if this request should not be validated first by a TSC vote or at least shared on the TSC mailing list to verify that there is no objection. It would also be advisable to designate maintainer(s) for this repo. Regards, Arnaud From: Dan Milea <danut.milea(a)windriver.com> Sent: mercredi 24 février 2021 15:52 To: Ed T. Mooring <emooring(a)xilinx.com>; Arnaud POULIQUEN <arnaud.pouliquen(a)st.com> Cc: Woolley, Rob <Rob.Woolley(a)windriver.com>; Bill Mills <bill.mills(a)linaro.org>; Tomas Evensen <tomase(a)xilinx.com>; Nathalie Chan King Choy <nathalie(a)xilinx.com>; Koning, Maarten <maarten.koning(a)windriver.com> Subject: Re: git repos for OpenAMP Appl Svcs WG Hi Ed, Arnaud, The repo we want to create under the OpenAMP github organization is a clone of kvmtool (https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/) with patches to support booting VxWorks as a KVM guest and for running as a Physical Machine Manager (aka virtio backend) in a hypervisor-less configuration (details here: https://github.com/OpenAMP/open-amp/wiki/OpenAMP-Application-Services-Subgr…). Work is under way to create a public virtio front-end implementation based on Zephyr to complete the hypervisor-less end-to-end scenario. Regards, Dan On 2/23/21 10:56 PM, Nathalie Chan King Choy wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] +Bill, Ed, Arnaud Hi Maarten & Dan, Ed & Arnaud have the owner role for https://github.com/OpenAMP -Nathalie From: Koning, Maarten <maarten.koning(a)windriver.com><mailto:maarten.koning@windriver.com> Sent: Tuesday, February 23, 2021 12:52 PM To: Tomas Evensen <tomase(a)xilinx.com><mailto:tomase@xilinx.com> Cc: Milea, Danut Gabriel (Danut) <Danut.Milea(a)windriver.com><mailto:Danut.Milea@windriver.com>; Woolley, Rob <Rob.Woolley(a)windriver.com><mailto:Rob.Woolley@windriver.com>; Nathalie Chan King Choy <nathalie(a)xilinx.com><mailto:nathalie@xilinx.com> Subject: git repos for OpenAMP Appl Svcs WG Hi Tomas, Rob, copied, will be arranging for the Zephyr virtio work to go into the Zephyr git repo. He is coordinating that directly with the Zephyr project. You mentioned you have a Linaro person ready to collaborate on this. Is that Akashi Takahiro or someone else? Also, Dan, copied, will be pushing the RSLd variant of kvmtool/lkvm to an OpenAMP git repo. Who should he work with in the Linaro OpenAMP project to ensure he does that push appropriately? Thanks, Maarten

5 years, 3 months

2
1
0 0

2020-12-04 OpenAMP TSC notes and action items

by Nathalie Chan King Choy

Hi all, You can find the notes posted here: https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20201204 If you spoke, please check for any errors or important omissions & feel free to make corrections in the wiki directly. == Action items == * Ed can reach out to former documentation lead at Docker to see if she knows anyone * Tomas can reach out to a very technical doc writer * Nathalie can reach out to Opersys * All: Does your company have any OpenAMP documentation that we can open source? * Bill M can start a thread with TF, OP-TEE & OpenAMP TSC about MISRA * Nathalie: Schedule next call for February Thanks & regards, Nathalie

5 years, 6 months

1
0
0 0

December TSC: Calling for agenda items

by Nathalie Chan King Choy

Hi all, Here are some agenda items for this Friday. Please let me know if you have others: * In October, Stefano presented Xen's consensus & conflict resolution & sent out the slides after. Are we ready to formalize the consensus & conflict resolution for OpenAMP? * Areas where it could be beneficial to have a professional tech writer work on OpenAMP documentation * In April, regarding coding guidelines, we had said we'd wait & see what Zephyr and Xen do regarding MISRA. Is this a topic to start discussing this call, prep for next call, or do we want to revisit mid-2021? Action items from the previous calls are below. Thanks & regards, Nathalie Hi all, The notes from the previous call (Oct 10) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20201009 Outstanding action items from the previous calls: * All: Please contact Tomas & Nathalie if you are interested in being on the Code of Conduct committee. * All: If you have ideas for licenses or other items for our small budget, let the OpenAMP Board members know. * All: If you know anyone we should reach out to, who isn't yet active in OpenAMP, but it would make sense for them, please let Tomas & Nathalie know. * Maarten to post his app-services slides * Maarten to look into making a public repo of the app-services work so far * Stefano to share his slides [DONE - here<http://lists.openampproject.org/pipermail/tsc/attachments/20201009/a133ac79…>] I put the Governance info from Ed's Word document into GitHub to make it easier to update as we make decisions & have it reflected on the project website. https://github.com/OpenAMP/website/blob/master/_pages/governance.md Currently, you need to know this link to see it on the website: https://www.openampproject.org/governance/ I will link to it from the main page after the TSC call, to give everyone time to review it. Let me know if you spot any errors. For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community

5 years, 6 months

1
0
0 0

OpenAMP TSC - December call

by Nathalie Chan King Choy

Hi all, The notes from the previous call (Oct 10) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20201009 Outstanding action items from the previous calls: * All: Please contact Tomas & Nathalie if you are interested in being on the Code of Conduct committee. * All: If you have ideas for licenses or other items for our small budget, let the OpenAMP Board members know. * All: If you know anyone we should reach out to, who isn't yet active in OpenAMP, but it would make sense for them, please let Tomas & Nathalie know. * Maarten to post his app-services slides * Maarten to look into making a public repo of the app-services work so far * Stefano to share his slides [DONE - here<http://lists.openampproject.org/pipermail/tsc/attachments/20201009/a133ac79…>] I put the Governance info from Ed's Word document into GitHub to make it easier to update as we make decisions & have it reflected on the project website. https://github.com/OpenAMP/website/blob/master/_pages/governance.md Currently, you need to know this link to see it on the website: https://www.openampproject.org/governance/ I will link to it from the main page after the TSC call, to give everyone time to review it. Let me know if you spot any errors. For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community Meeting number (access code): 145 623 7036 Meeting password: 7BJqJn3Fe@3 Friday, December 4, 2020 7:00 am | (UTC-08:00) Pacific Time (US & Canada) | 1 hr Join meeting<https://xilinx.webex.com/xilinx/j.php?MTID=m02de97bd5c964a2382d3bc73a0c00c49> Join by phone Webex United States Toll Free 1-844-621-3956 Canada Toll Free 1-844-426-4405 France Toll Free 0800-912-485 United Kingdom Toll Free 08000315372 Sweden Toll Free 020-033-6721 India Toll Free 000-800-040-1016 Global call-in numbers<https://xilinx.webex.com/xilinx/globalcallin.php?MTID=mc238dfa5b4765667c387…> | Toll-free calling restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf>

5 years, 6 months

1
0
0 0

OpenAMP documentation: gaps & low hanging fruit

by Nathalie Chan King Choy

Hi OpenAMP TSC, We have some OpenAMP Community Project budget available and one suggestion was to consider hiring a professional technical writer to do some work on the OpenAMP documentation. Yocto Project has benefitted from investing in a professional technical writer for their docs. If you are aware of specific gaps in the documentation, especially low hanging fruit, which could be remedied by some tech writer contracting hours, please let us know. Your suggestions will be used to figure out cost & come up with a proposal. Also, if you can suggest suitable tech writer candidates, please send me a message directly. Thanks & have a great weekend, Nathalie

5 years, 7 months

1
0
0 0

2020-10-09 OpenAMP TSC notes and action items

by Nathalie Chan King Choy

Hi all, You can find the notes posted here: https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20201009 If you spoke, please check for any errors or important omissions & feel free to make corrections in the wiki directly. Action items: * Maarten to post his app-services slides (can just send an email to the TSC list) * Maarten to look into making a public repo of the app-services work so far * Stefano to share his slides [DONE - link is also in the notes] Thanks & have a great weekend, Nathalie

5 years, 8 months

1
0
0 0

Re: [OA-Tsc] Agenda for OpenAMP TSC call on October 9th

by Stefano Stabellini

On Thu, 8 Oct 2020, Nathalie Chan King Choy via Tsc wrote: > Hi all, > > > > Here is the proposed agenda: > > > > * What are the working groups’ goals for the next 6 months? > > * Does the TSC have feedback on those goals? > > * Do those goals require any budget $? (e.g. tools licenses) > > * Governance: Stefano to present how Xen Project makes decisions and resolves conflicts Hi all, I am attaching the small slidedeck I presented this morning. Cheers, Stefano

5 years, 8 months

1
0
0 0

Re: [OA-Tsc] Agenda for OpenAMP TSC call on October 9th

by Bill Mills

Nathalie & All, I will be traveling by car today. I will join if at all possible. WRT: goals for openamp-rp for next 6 months * continued upstreaming of vendor patches * name service extension finalization * Detach model upstream * Possible protocol changes to support this fully * CI * rpmsg char create / destroy channels from userspace * rpmsg tty Thanks, Bill On 10/8/20 2:48 AM, Nathalie Chan King Choy via Tsc wrote: > Hi all, > > Here is the proposed agenda: > > * What are the working groups’ goals for the next 6 months? > > * Does the TSC have feedback on those goals? > > * Do those goals require any budget $? (e.g. tools licenses) > > * Governance: Stefano to present how Xen Project makes decisions and > resolves conflicts > > * Governance: Discuss the next open item(s) on > https://github.com/OpenAMP/website/blob/master/_pages/governance.md > > Also, I have posted some news to the project website: > https://www.openampproject.org/news/ > > You can find the links to the ELCNA20 OpenAMP presentation recording, > the OpenAMP white paper, and the MGC Electronic Design Magazine article > in the posts. > > Thanks & regards, > > Nathalie > > *From:*Tsc <tsc-bounces(a)lists.openampproject.org> *On Behalf Of > *Nathalie Chan King Choy via Tsc > *Sent:* Friday, October 2, 2020 9:18 AM > *To:* tsc(a)lists.openampproject.org > *Subject:* [OA-Tsc] Calling for agenda items: OpenAMP TSC - October call > > CAUTION:This message has originated from an External Source. Please use > proper judgment and caution when opening attachments, clicking links, or > responding to this email. > > Hi all, > > Please send your requests for agenda items. Action items from the > previous call are below. > > Have a wonderful weekend, > > Nathalie > > -----Original Appointment----- > *From:* Nathalie Chan King Choy > *Sent:* Monday, September 14, 2020 2:30 PM > *Subject:* OpenAMP TSC - October call > *When:* Friday, October 9, 2020 7:00 AM-8:00 AM (UTC-08:00) Pacific Time > (US & Canada). > *Where:* Webex > > Hi all, > > The notes from the previous call (July 23) can be found at > https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20200723 > > I put the Governance info from Ed’s Word document into GitHub to make it > easier to update as we make decisions & have it reflected on the project > website. > > https://github.com/OpenAMP/website/blob/master/_pages/governance.md > > Currently, you need to know this link to see it on the website: > https://www.openampproject.org/governance/ > > I will link to it from the main page after the TSC call, to give > everyone time to review it. Let me know if you spot any errors. > > Outstanding action items from the previous call: > > * All: Please contact Tomas & Nathalie if you are interested in being > on the Code of Conduct committee. > * All: If you have ideas for licenses or other items for our small > budget, let the OpenAMP Board members know. > * All: If you know anyone we should reach out to, who isn't yet active > in OpenAMP, but it would make sense for them, please let Tomas & > Nathalie know. > > For info about the list, link to the archives, to unsubscribe yourself, > or for someone to subscribe themselves, visit: > > https://lists.openampproject.org/mailman/listinfo/tsc > > Best regards, > > Nathalie C. Chan King Choy > > Program Manager focused on Open Source and Community > > Meeting number (access code): 145 979 2059 > > Meeting password: WeZ7bRnt*25 > > Friday, October 9, 2020 > > 7:00 am | (UTC-07:00) Pacific Time (US & Canada) | 1 hr > > Join meeting > <https://xilinx.webex.com/xilinx/j.php?MTID=m10c07949d36605d6e9a4cb72b48e3795> > > *Join by phone* > > Canada toll free 1-844-426-4405 > > France toll free 0800-912-485 > > India toll free 000-800-040-1016 > > Sweden toll free 020-033-6721 > > UK toll free 08000315372 > > United States Toll Free 1-844-621-3956 > >

5 years, 8 months

1
0
0 0

Agenda for OpenAMP TSC call on October 9th

by Nathalie Chan King Choy

Hi all, Here is the proposed agenda: * What are the working groups' goals for the next 6 months? * Does the TSC have feedback on those goals? * Do those goals require any budget $? (e.g. tools licenses) * Governance: Stefano to present how Xen Project makes decisions and resolves conflicts * Governance: Discuss the next open item(s) on https://github.com/OpenAMP/website/blob/master/_pages/governance.md Also, I have posted some news to the project website: https://www.openampproject.org/news/ You can find the links to the ELCNA20 OpenAMP presentation recording, the OpenAMP white paper, and the MGC Electronic Design Magazine article in the posts. Thanks & regards, Nathalie From: Tsc <tsc-bounces(a)lists.openampproject.org> On Behalf Of Nathalie Chan King Choy via Tsc Sent: Friday, October 2, 2020 9:18 AM To: tsc(a)lists.openampproject.org Subject: [OA-Tsc] Calling for agenda items: OpenAMP TSC - October call CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email. Hi all, Please send your requests for agenda items. Action items from the previous call are below. Have a wonderful weekend, Nathalie -----Original Appointment----- From: Nathalie Chan King Choy Sent: Monday, September 14, 2020 2:30 PM Subject: OpenAMP TSC - October call When: Friday, October 9, 2020 7:00 AM-8:00 AM (UTC-08:00) Pacific Time (US & Canada). Where: Webex Hi all, The notes from the previous call (July 23) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20200723 I put the Governance info from Ed's Word document into GitHub to make it easier to update as we make decisions & have it reflected on the project website. https://github.com/OpenAMP/website/blob/master/_pages/governance.md Currently, you need to know this link to see it on the website: https://www.openampproject.org/governance/ I will link to it from the main page after the TSC call, to give everyone time to review it. Let me know if you spot any errors. Outstanding action items from the previous call: * All: Please contact Tomas & Nathalie if you are interested in being on the Code of Conduct committee. * All: If you have ideas for licenses or other items for our small budget, let the OpenAMP Board members know. * All: If you know anyone we should reach out to, who isn't yet active in OpenAMP, but it would make sense for them, please let Tomas & Nathalie know. For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community Meeting number (access code): 145 979 2059 Meeting password: WeZ7bRnt*25 Friday, October 9, 2020 7:00 am | (UTC-07:00) Pacific Time (US & Canada) | 1 hr Join meeting<https://xilinx.webex.com/xilinx/j.php?MTID=m10c07949d36605d6e9a4cb72b48e3795> Join by phone Canada toll free 1-844-426-4405 France toll free 0800-912-485 India toll free 000-800-040-1016 Sweden toll free 020-033-6721 UK toll free 08000315372 United States Toll Free 1-844-621-3956

5 years, 8 months

1
0
0 0

Calling for agenda items: OpenAMP TSC - October call

by Nathalie Chan King Choy

Hi all, Please send your requests for agenda items. Action items from the previous call are below. Have a wonderful weekend, Nathalie -----Original Appointment----- From: Nathalie Chan King Choy Sent: Monday, September 14, 2020 2:30 PM Subject: OpenAMP TSC - October call When: Friday, October 9, 2020 7:00 AM-8:00 AM (UTC-08:00) Pacific Time (US & Canada). Where: Webex Hi all, The notes from the previous call (July 23) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20200723 I put the Governance info from Ed's Word document into GitHub to make it easier to update as we make decisions & have it reflected on the project website. https://github.com/OpenAMP/website/blob/master/_pages/governance.md Currently, you need to know this link to see it on the website: https://www.openampproject.org/governance/ I will link to it from the main page after the TSC call, to give everyone time to review it. Let me know if you spot any errors. Outstanding action items from the previous call: * All: Please contact Tomas & Nathalie if you are interested in being on the Code of Conduct committee. * All: If you have ideas for licenses or other items for our small budget, let the OpenAMP Board members know. * All: If you know anyone we should reach out to, who isn't yet active in OpenAMP, but it would make sense for them, please let Tomas & Nathalie know. For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community Meeting number (access code): 145 979 2059 Meeting password: WeZ7bRnt*25 Friday, October 9, 2020 7:00 am | (UTC-07:00) Pacific Time (US & Canada) | 1 hr Join meeting<https://xilinx.webex.com/xilinx/j.php?MTID=m10c07949d36605d6e9a4cb72b48e3795> Join by phone Canada toll free 1-844-426-4405 France toll free 0800-912-485 India toll free 000-800-040-1016 Sweden toll free 020-033-6721 UK toll free 08000315372 United States Toll Free 1-844-621-3956

5 years, 8 months

1
0
0 0

OpenAMP TSC - October call

by Nathalie Chan King Choy

Hi all, The notes from the previous call (July 23) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20200723 I put the Governance info from Ed's Word document into GitHub to make it easier to update as we make decisions & have it reflected on the project website. https://github.com/OpenAMP/website/blob/master/_pages/governance.md Currently, you need to know this link to see it on the website: https://www.openampproject.org/governance/ I will link to it from the main page after the TSC call, to give everyone time to review it. Let me know if you spot any errors. Outstanding action items from the previous call: * All: Please contact Tomas & Nathalie if you are interested in being on the Code of Conduct committee. * All: If you have ideas for licenses or other items for our small budget, let the OpenAMP Board members know. * All: If you know anyone we should reach out to, who isn't yet active in OpenAMP, but it would make sense for them, please let Tomas & Nathalie know. For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community Meeting number (access code): 145 979 2059 Meeting password: WeZ7bRnt*25 Friday, October 9, 2020 7:00 am | (UTC-07:00) Pacific Time (US & Canada) | 1 hr Join meeting<https://xilinx.webex.com/xilinx/j.php?MTID=m10c07949d36605d6e9a4cb72b48e3795> Join by phone Canada toll free 1-844-426-4405 France toll free 0800-912-485 India toll free 000-800-040-1016 Sweden toll free 020-033-6721 UK toll free 08000315372 United States Toll Free 1-844-621-3956

5 years, 9 months

1
0
0 0

Scheduling next TSC call: Sept -> Oct?

by Nathalie Chan King Choy

Hi OpenAMP TSC, At our last TSC call in July, we had talked about having the next call in September, before Linaro Virtual Connect, so that we could discuss the OpenAMP Project Update slides for the Linaro Virtual Connect session. However, it turns out that the slides deadline is Sept 16th and in the week of Sept 7th we have calls scheduled for OpenAMP App-services, OpenAMP Board, and (typically*) OpenAMP remote-proc, so having an OpenAMP TSC call seems a bit much, given the overlap in attendance among the calls. (*I believe Bill M. will be sending a new meeting series.) Would anyone be opposed to having the next TSC call in October, to spread things out a bit? We can discuss interesting things that came out of Linaro Virtual Connect sessions. Thanks & regards, Nathalie P.S. If anyone had their heart set on participating in the slides review for the OpenAMP Project Update, email me directly & I'll include you when we review over email.

5 years, 10 months

1
0
0 0

2020-07-23 OpenAMP TSC notes and action items

by Nathalie Chan King Choy

Hi all, You can find the notes posted here: https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020 If you spoke, please check for any errors or important omissions & feel free to make corrections in the wiki directly. Action items: * All: Please contact Tomas & Nathalie if you are interested in being on the Code of Conduct committee. * All: If you have ideas for licenses or other items for our small budget, let the OpenAMP Board members know. * All: If you know anyone we should reach out to, who isn't yet active in OpenAMP, but it would make sense for them, please let Tomas & Nathalie know. * Stefano to send out example of Xen consensus & conflict resolution process * Nathalie: Shoot for 2nd week of September for TSC to schedule next call * Nathalie: Send a question to list about rescheduling app-services call to September Thanks & regards, Nathalie

5 years, 10 months

1
0
0 0

update of the cmake minimum version for openamp and libmetal libraries

by Arnaud POULIQUEN

Dear TSC members, Ed and I are having a discussion about the minimal version of cmake that we should support for the openamp and libmetal libraries. Today, the minimum supported version (checked during cmake runtime) is cmake v2.6. This constraint on the minimum supported version was specified when the libraries were created and has never been updated. In our environment we test the libraries with cmake V3.x, so cmake v2.6 support is no longer guaranteed. Our proposal is to update the minimum version to 3.5 which corresponds to a version that we can simply test as part of the Ubuntu Xenial (16.04 LTS) distribution. This could be effective for next October release. As this update may be part of the stability policy, we would like to be sure that there are no objections from members before proposing a pull request.. So, If you have any objections or concerns about this update, please let us know. Thanks and Regards, Arnaud

5 years, 11 months

1
0
0 0

OpenAMP TSC - July 2020

by Nathalie Chan King Choy

Hi all, Please join on Zoom: https://zoom.us/my/openampproject I will email out the password directly to list members the day before the call. The notes from the previous call (May 12) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20200512 Action items from the previous call: * All: Continue API discussion by email (See https://lists.openampproject.org/pipermail/tsc/2020-May/thread.html#start) * Stefano & Bruce: Document System DT & Lopper goals in OpenAMP Wiki at https://github.com/OpenAMP/open-amp/wiki/Future-Topics-for-System-Device-Tr… * Ed: Update the governance document to reflect what we're actually doing (See https://lists.openampproject.org/pipermail/tsc/2020-June/000070.html for the attachment) * Ed to do gap analysis of OpenAMP documentation & look at using Sphinx * Nathalie: Schedule next TSC call for July For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community One tap mobile +13126266799,,9031895760# US (Chicago) +16465588656,,9031895760# US (New York) Dial by your location +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) +1 253 215 8782 US +1 301 715 8592 US +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 903 189 5760 Find your local number: https://zoom.us/u/aAZAtnejF

5 years, 11 months

1
0
0 0

Updated Governance Document

by Ed T. Mooring

Hi all, Per our last meeting, I have updated the governance document to reflect current practice. Regards, Ed M This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

6 years

1
0
0 0

Re: [OA-Tsc] API and Wire protocol stability

by Arnaud POULIQUEN

Hi Bill, On 5/20/20 6:04 AM, Mills, William via Tsc wrote: > Arnaud, > > Thanks for the review. > > WRT to memory footprint and no dynamic memory allocation > > I wonder if these are better handled with test cases? > Or are you worried that it is too easy to change the test case? Yes testing is a good solution to verify the requirements. However, my concern here is more that these legacy requirements are not specified in OpenAMP project. Personally, i am still applying a default policy on them even if there are not specified. But like the API, does this makes sense for every members? That's why I would suggest that these requirements be re-validated by the TSC members and that we find a way (policy, guideline, other...) to clarify them in the documentation. Thanks, Arnaud > > Thanks, > Bill > > -----Original Message----- > From: Tsc [mailto:tsc-bounces@lists.openampproject.org] On Behalf Of Nathalie Chan King Choy via Tsc > Sent: Tuesday, May 19, 2020 12:23 PM > To: tsc(a)lists.openampproject.org > Subject: [OA-Tsc] FW: API and Wire protocol stability > > Message went to tsc-bounces instead of tsc list. > > -----Original Message----- > From: Arnaud POULIQUEN <arnaud.pouliquen(a)st.com> > Sent: Tuesday, May 19, 2020 8:50 AM > To: Mills, William <wmills(a)ti.com> > Cc: tsc-bounces(a)lists.openampproject.org > Subject: RE: API and Wire protocol stability > > Hi Bill, all > > Thanks Bill for this proposal. Look to me a good approach. > > Could version number management in openAMP help applications to better manage API and Wire protocol evolution? > Today the status is: > - libmetal: API fo get lib version exists ( MAJOR.MINOR.PATCH format) but no evolution of the version since a while: Current version 0.1.0 > - OpenAMP: version only handled for Zephyr with same format than libmetal, no API to get the library version. Current version 0.1.0 > > > Another point, probably quite out of scope here, but reviewing this policy reminds me some of the requirements that were defined when we started the OpenAMP library redesign in 2018. > > - The first was the library's memory footprint. This requirement was a condition for the viability of OpenAMP on > MCU with low memory. The target was 3 kB for the ROM. Today, we are close to ( but higher than) this target. And the footprint continue to grow by adding > fixes and new features. For instance, the cost of integrating the "zero copy" feature is about 0.5 KB. > > - The second was the support of systems without dynamic allocation. Today, I think we are still meeting this requirement. > > I wonder whether these requirements should not be reshaped in policies, as they also have an impact on the evolution of the library. > So I would appreciate if we can also clarify this 2 points, (after the API and wire protocol policies, of course :) ) > > Thanks > Arnaud > >> -----Original Message----- >> From: Tsc <tsc-bounces(a)lists.openampproject.org> On Behalf Of Mills, >> William via Tsc >> Sent: samedi 18 avril 2020 17:41 >> To: tsc(a)lists.openampproject.org >> Subject: [OA-Tsc] API and Wire protocol stability >> >> All, >> >> I have the action to write up thought on API stability. >> On 4/17 we added wire protocol stability to the list. >> There is also discussion of API homogeneity across different >> implementations and/or operating environments but that topic is out of >> scope for this discussion and I specifically opted out of leading that >> discussion. >> >> **** API Stability: >> >> For reference here is the Zephyr policy on API lifecycle: >> https://docs.zephyrproject.org/latest/development_process/api_lifecycle.h >> tml >> >> ** Scope: >> >> The scope of the OpenAMP API lifecycle policy is mostly the libraries and >> supporting code owned by the project. >> Today that is primarily the open-amp and libmetal libraries but we expect >> that to expand in the future. >> >> Specifically out of scope would be the APIs internal to the Linux kernel. The >> Linux kernel has a famous "no stable api" policy. >> Probably also out of scope would be the kernel / user interface. This >> interface has a more stringent "don't break the user interface policy" than >> will be described here. >> >> Nothing prevents us from trying to apply our policies to the Linux kernel on a >> best effort basis but we need to understand the kernel's policies will >> override ours in a conflict. >> >> ** Why have a policy?: >> >> One possible policy is to have no policy or a weak one. Under such a policy, >> If someone is using the old API's, let then use the old version of the library. >> When they want to upgrade to a new version, they should upgrade to the >> new APIs as well. >> >> I don't think a weak policy is wise. We are a small project and don't want to >> maintain and test many versions of the libraries. To date we don't have an >> LTS policy and I think it would be good if we did not have to go there. A >> strong API stability statement means that users can pick up bug fixes, new >> platforms and even some new features without having to change [much] of >> their application/system. Even if we define an LTS policy a stable API policy >> lowers the barrier to pick up that one new feature you need. >> >> ** Comments on the Zephyr policy: >> >> OpenAMP is a smaller project than Zephyr so I think we can simplify the >> model a bit. >> Certainly we want the API states of stable, deprecated, and removed. >> I don't see any need to have two states before stable. >> "Experimental" APIs should not be in the release branches, they should be in >> experimental branches or git repo forks. >> You could say the same for "Unstable" but there are valid reasons to include >> it as well. >> >> The Zephyr policy says things stay in depreciated state for 2 releases. Zephyr >> makes releases ~ 2 times per year. So applications have to upgrade versions >> at least once a year to have any benefit from the policy. This seems very >> short to me. A 2 year depreciation stay seems more appropriate to me. >> Another approach would be to specify a minimum and a maximum time in >> deprecated state. Things that are easy to keep can stay for the max time and >> things that cause big headaches to maintain can stay for the minimum time. >> >> ** Mechanism of compatibility >> >> As with the Zephyr policy we are focused on source level compatibility. It is >> acceptable if the user has to recompile his application to use the new library >> version. >> >> Maintaining a binary level API (more correctly an ABI) is a decent amount of >> extra work. If we do have Linux shared libraries that get commonly used we >> will need to look at this. However, I suggest we tackle that issues as it arises. >> (A static library does not have the same issue) >> >> **** Wire Protocol Stability: >> >> The wire protocol describes the interactions of two independent CPUs in an >> AMP system. The bar for maintaining compatibility at this level is much >> higher. >> >> Some random thoughts/suggestions: >> >> (I am using "firmware" and "kernel" as stand-ins for the more general cases >> also) >> >> * break of compatibility of the protocol level should require TSC approval >> * New kernels should run old firmware >> * New firmware that has extra features with new kernels should still work >> with old kernels if that is desired >> * We need to know what properties of interaction are guaranteed vs just >> how the current implementation works today >> ** We need a protocol document >> ** Until we do, we have to treat current UPSTREAM model as the defacto >> standard >> ** We can't really have protocol compatibility states until we have a protocol >> document >> ** Anything currently only in vendor branches is considered Experimental >> * New Protocol features and versions are best if they can be discovered live >> ** However manual opt-in by both parties is acceptable as a fallback >> >> Thanks, >> Bill >> >> >> --------------------------------------------------- >> William A. Mills >> Chief Technologist, Open Source >> Texas Instruments, Processors >> 20250 Century Blvd, Suit 300 >> Germantown MD, 20874 >> (work/mobile) +1-240-643-0836 >> >> >> -- >> Tsc mailing list >> Tsc(a)lists.openampproject.org >> https://lists.openampproject.org/mailman/listinfo/tsc >

6 years

1
0
0 0

Re: [OA-Tsc] API and Wire protocol stability

by Mills, William

Arnaud, Thanks for the review. WRT to memory footprint and no dynamic memory allocation I wonder if these are better handled with test cases? Or are you worried that it is too easy to change the test case? Thanks, Bill -----Original Message----- From: Tsc [mailto:tsc-bounces@lists.openampproject.org] On Behalf Of Nathalie Chan King Choy via Tsc Sent: Tuesday, May 19, 2020 12:23 PM To: tsc(a)lists.openampproject.org Subject: [OA-Tsc] FW: API and Wire protocol stability Message went to tsc-bounces instead of tsc list. -----Original Message----- From: Arnaud POULIQUEN <arnaud.pouliquen(a)st.com> Sent: Tuesday, May 19, 2020 8:50 AM To: Mills, William <wmills(a)ti.com> Cc: tsc-bounces(a)lists.openampproject.org Subject: RE: API and Wire protocol stability Hi Bill, all Thanks Bill for this proposal. Look to me a good approach. Could version number management in openAMP help applications to better manage API and Wire protocol evolution? Today the status is: - libmetal: API fo get lib version exists ( MAJOR.MINOR.PATCH format) but no evolution of the version since a while: Current version 0.1.0 - OpenAMP: version only handled for Zephyr with same format than libmetal, no API to get the library version. Current version 0.1.0 Another point, probably quite out of scope here, but reviewing this policy reminds me some of the requirements that were defined when we started the OpenAMP library redesign in 2018. - The first was the library's memory footprint. This requirement was a condition for the viability of OpenAMP on MCU with low memory. The target was 3 kB for the ROM. Today, we are close to ( but higher than) this target. And the footprint continue to grow by adding fixes and new features. For instance, the cost of integrating the "zero copy" feature is about 0.5 KB. - The second was the support of systems without dynamic allocation. Today, I think we are still meeting this requirement. I wonder whether these requirements should not be reshaped in policies, as they also have an impact on the evolution of the library. So I would appreciate if we can also clarify this 2 points, (after the API and wire protocol policies, of course :) ) Thanks Arnaud > -----Original Message----- > From: Tsc <tsc-bounces(a)lists.openampproject.org> On Behalf Of Mills, > William via Tsc > Sent: samedi 18 avril 2020 17:41 > To: tsc(a)lists.openampproject.org > Subject: [OA-Tsc] API and Wire protocol stability > > All, > > I have the action to write up thought on API stability. > On 4/17 we added wire protocol stability to the list. > There is also discussion of API homogeneity across different > implementations and/or operating environments but that topic is out of > scope for this discussion and I specifically opted out of leading that > discussion. > > **** API Stability: > > For reference here is the Zephyr policy on API lifecycle: > https://docs.zephyrproject.org/latest/development_process/api_lifecycle.h > tml > > ** Scope: > > The scope of the OpenAMP API lifecycle policy is mostly the libraries and > supporting code owned by the project. > Today that is primarily the open-amp and libmetal libraries but we expect > that to expand in the future. > > Specifically out of scope would be the APIs internal to the Linux kernel. The > Linux kernel has a famous "no stable api" policy. > Probably also out of scope would be the kernel / user interface. This > interface has a more stringent "don't break the user interface policy" than > will be described here. > > Nothing prevents us from trying to apply our policies to the Linux kernel on a > best effort basis but we need to understand the kernel's policies will > override ours in a conflict. > > ** Why have a policy?: > > One possible policy is to have no policy or a weak one. Under such a policy, > If someone is using the old API's, let then use the old version of the library. > When they want to upgrade to a new version, they should upgrade to the > new APIs as well. > > I don't think a weak policy is wise. We are a small project and don't want to > maintain and test many versions of the libraries. To date we don't have an > LTS policy and I think it would be good if we did not have to go there. A > strong API stability statement means that users can pick up bug fixes, new > platforms and even some new features without having to change [much] of > their application/system. Even if we define an LTS policy a stable API policy > lowers the barrier to pick up that one new feature you need. > > ** Comments on the Zephyr policy: > > OpenAMP is a smaller project than Zephyr so I think we can simplify the > model a bit. > Certainly we want the API states of stable, deprecated, and removed. > I don't see any need to have two states before stable. > "Experimental" APIs should not be in the release branches, they should be in > experimental branches or git repo forks. > You could say the same for "Unstable" but there are valid reasons to include > it as well. > > The Zephyr policy says things stay in depreciated state for 2 releases. Zephyr > makes releases ~ 2 times per year. So applications have to upgrade versions > at least once a year to have any benefit from the policy. This seems very > short to me. A 2 year depreciation stay seems more appropriate to me. > Another approach would be to specify a minimum and a maximum time in > deprecated state. Things that are easy to keep can stay for the max time and > things that cause big headaches to maintain can stay for the minimum time. > > ** Mechanism of compatibility > > As with the Zephyr policy we are focused on source level compatibility. It is > acceptable if the user has to recompile his application to use the new library > version. > > Maintaining a binary level API (more correctly an ABI) is a decent amount of > extra work. If we do have Linux shared libraries that get commonly used we > will need to look at this. However, I suggest we tackle that issues as it arises. > (A static library does not have the same issue) > > **** Wire Protocol Stability: > > The wire protocol describes the interactions of two independent CPUs in an > AMP system. The bar for maintaining compatibility at this level is much > higher. > > Some random thoughts/suggestions: > > (I am using "firmware" and "kernel" as stand-ins for the more general cases > also) > > * break of compatibility of the protocol level should require TSC approval > * New kernels should run old firmware > * New firmware that has extra features with new kernels should still work > with old kernels if that is desired > * We need to know what properties of interaction are guaranteed vs just > how the current implementation works today > ** We need a protocol document > ** Until we do, we have to treat current UPSTREAM model as the defacto > standard > ** We can't really have protocol compatibility states until we have a protocol > document > ** Anything currently only in vendor branches is considered Experimental > * New Protocol features and versions are best if they can be discovered live > ** However manual opt-in by both parties is acceptable as a fallback > > Thanks, > Bill > > > --------------------------------------------------- > William A. Mills > Chief Technologist, Open Source > Texas Instruments, Processors > 20250 Century Blvd, Suit 300 > Germantown MD, 20874 > (work/mobile) +1-240-643-0836 > > > -- > Tsc mailing list > Tsc(a)lists.openampproject.org > https://lists.openampproject.org/mailman/listinfo/tsc -- Tsc mailing list Tsc(a)lists.openampproject.org https://lists.openampproject.org/mailman/listinfo/tsc

6 years

1
0
0 0

FW: API and Wire protocol stability

by Nathalie Chan King Choy

Message went to tsc-bounces instead of tsc list. -----Original Message----- From: Arnaud POULIQUEN <arnaud.pouliquen(a)st.com> Sent: Tuesday, May 19, 2020 8:50 AM To: Mills, William <wmills(a)ti.com> Cc: tsc-bounces(a)lists.openampproject.org Subject: RE: API and Wire protocol stability Hi Bill, all Thanks Bill for this proposal. Look to me a good approach. Could version number management in openAMP help applications to better manage API and Wire protocol evolution? Today the status is: - libmetal: API fo get lib version exists ( MAJOR.MINOR.PATCH format) but no evolution of the version since a while: Current version 0.1.0 - OpenAMP: version only handled for Zephyr with same format than libmetal, no API to get the library version. Current version 0.1.0 Another point, probably quite out of scope here, but reviewing this policy reminds me some of the requirements that were defined when we started the OpenAMP library redesign in 2018. - The first was the library's memory footprint. This requirement was a condition for the viability of OpenAMP on MCU with low memory. The target was 3 kB for the ROM. Today, we are close to ( but higher than) this target. And the footprint continue to grow by adding fixes and new features. For instance, the cost of integrating the "zero copy" feature is about 0.5 KB. - The second was the support of systems without dynamic allocation. Today, I think we are still meeting this requirement. I wonder whether these requirements should not be reshaped in policies, as they also have an impact on the evolution of the library. So I would appreciate if we can also clarify this 2 points, (after the API and wire protocol policies, of course :) ) Thanks Arnaud > -----Original Message----- > From: Tsc <tsc-bounces(a)lists.openampproject.org> On Behalf Of Mills, > William via Tsc > Sent: samedi 18 avril 2020 17:41 > To: tsc(a)lists.openampproject.org > Subject: [OA-Tsc] API and Wire protocol stability > > All, > > I have the action to write up thought on API stability. > On 4/17 we added wire protocol stability to the list. > There is also discussion of API homogeneity across different > implementations and/or operating environments but that topic is out of > scope for this discussion and I specifically opted out of leading that > discussion. > > **** API Stability: > > For reference here is the Zephyr policy on API lifecycle: > https://docs.zephyrproject.org/latest/development_process/api_lifecycle.h > tml > > ** Scope: > > The scope of the OpenAMP API lifecycle policy is mostly the libraries and > supporting code owned by the project. > Today that is primarily the open-amp and libmetal libraries but we expect > that to expand in the future. > > Specifically out of scope would be the APIs internal to the Linux kernel. The > Linux kernel has a famous "no stable api" policy. > Probably also out of scope would be the kernel / user interface. This > interface has a more stringent "don't break the user interface policy" than > will be described here. > > Nothing prevents us from trying to apply our policies to the Linux kernel on a > best effort basis but we need to understand the kernel's policies will > override ours in a conflict. > > ** Why have a policy?: > > One possible policy is to have no policy or a weak one. Under such a policy, > If someone is using the old API's, let then use the old version of the library. > When they want to upgrade to a new version, they should upgrade to the > new APIs as well. > > I don't think a weak policy is wise. We are a small project and don't want to > maintain and test many versions of the libraries. To date we don't have an > LTS policy and I think it would be good if we did not have to go there. A > strong API stability statement means that users can pick up bug fixes, new > platforms and even some new features without having to change [much] of > their application/system. Even if we define an LTS policy a stable API policy > lowers the barrier to pick up that one new feature you need. > > ** Comments on the Zephyr policy: > > OpenAMP is a smaller project than Zephyr so I think we can simplify the > model a bit. > Certainly we want the API states of stable, deprecated, and removed. > I don't see any need to have two states before stable. > "Experimental" APIs should not be in the release branches, they should be in > experimental branches or git repo forks. > You could say the same for "Unstable" but there are valid reasons to include > it as well. > > The Zephyr policy says things stay in depreciated state for 2 releases. Zephyr > makes releases ~ 2 times per year. So applications have to upgrade versions > at least once a year to have any benefit from the policy. This seems very > short to me. A 2 year depreciation stay seems more appropriate to me. > Another approach would be to specify a minimum and a maximum time in > deprecated state. Things that are easy to keep can stay for the max time and > things that cause big headaches to maintain can stay for the minimum time. > > ** Mechanism of compatibility > > As with the Zephyr policy we are focused on source level compatibility. It is > acceptable if the user has to recompile his application to use the new library > version. > > Maintaining a binary level API (more correctly an ABI) is a decent amount of > extra work. If we do have Linux shared libraries that get commonly used we > will need to look at this. However, I suggest we tackle that issues as it arises. > (A static library does not have the same issue) > > **** Wire Protocol Stability: > > The wire protocol describes the interactions of two independent CPUs in an > AMP system. The bar for maintaining compatibility at this level is much > higher. > > Some random thoughts/suggestions: > > (I am using "firmware" and "kernel" as stand-ins for the more general cases > also) > > * break of compatibility of the protocol level should require TSC approval > * New kernels should run old firmware > * New firmware that has extra features with new kernels should still work > with old kernels if that is desired > * We need to know what properties of interaction are guaranteed vs just > how the current implementation works today > ** We need a protocol document > ** Until we do, we have to treat current UPSTREAM model as the defacto > standard > ** We can't really have protocol compatibility states until we have a protocol > document > ** Anything currently only in vendor branches is considered Experimental > * New Protocol features and versions are best if they can be discovered live > ** However manual opt-in by both parties is acceptable as a fallback > > Thanks, > Bill > > > --------------------------------------------------- > William A. Mills > Chief Technologist, Open Source > Texas Instruments, Processors > 20250 Century Blvd, Suit 300 > Germantown MD, 20874 > (work/mobile) +1-240-643-0836 > > > -- > Tsc mailing list > Tsc(a)lists.openampproject.org > https://lists.openampproject.org/mailman/listinfo/tsc

6 years

1
0
0 0

Re: [OA-Tsc] API and Wire protocol stability

by William Mills

Grant, On 5/18/20 12:09 PM, Grant Likely via Tsc wrote: > Hi Bill, > > I don't have particularly strong opinions on the details of the policy. > I do agree it is important to start with something (can be adjusted as > the project goes along if necessary). Agree that being firm on wire > protocol stability (and I think versioning) is very important, and > you're thoughts on simplifying the Zepher model sound sensible. > > I would err toward not removing APIs, or moving them to a libcompat as > wrappers to their replacements. The latter approach has a nice benefit > of making it obvious when an API layer is no longer the preferred > interface because the compat lib needs to be linked in. > Yes I agree. I think moving to libcompat should be strongly recommended. Thanks for the review. -- Bill > g. > > On 14/05/2020 08:22, Nathalie Chan King Choy via Tsc wrote: >> Hi all, >> >> In today's TSC call, the suggestion was to continue this discussion >> over email >> & then come to a decision during the July TSC call. >> >> Thanks & regards, >> Nathalie >> >>> -----Original Message----- >>> From: Tsc <tsc-bounces(a)lists.openampproject.org> On Behalf Of Mills, >>> William via Tsc >>> Sent: Saturday, April 18, 2020 8:41 AM >>> To: tsc(a)lists.openampproject.org >>> Subject: [OA-Tsc] API and Wire protocol stability >>> >>> CAUTION: This message has originated from an External Source. Please use >>> proper judgment and caution when opening attachments, clicking links, or >>> responding to this email. >>> >>> >>> All, >>> >>> I have the action to write up thought on API stability. >>> On 4/17 we added wire protocol stability to the list. >>> There is also discussion of API homogeneity across different >>> implementations and/or operating environments but that topic is out of >>> scope for this discussion and I specifically opted out of leading that >>> discussion. >>> >>> **** API Stability: >>> >>> For reference here is the Zephyr policy on API lifecycle: >>> https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html >>> >>> >>> ** Scope: >>> >>> The scope of the OpenAMP API lifecycle policy is mostly the libraries >>> and >>> supporting code owned by the project. >>> Today that is primarily the open-amp and libmetal libraries but we >>> expect >>> that to expand in the future. >>> >>> Specifically out of scope would be the APIs internal to the Linux >>> kernel. The >>> Linux kernel has a famous "no stable api" policy. >>> Probably also out of scope would be the kernel / user interface. This >>> interface has a more stringent "don't break the user interface >>> policy" than >>> will be described here. >>> >>> Nothing prevents us from trying to apply our policies to the Linux >>> kernel on a >>> best effort basis but we need to understand the kernel's policies will >>> override ours in a conflict. >>> >>> ** Why have a policy?: >>> >>> One possible policy is to have no policy or a weak one. Under such a >>> policy, >>> If someone is using the old API's, let then use the old version of >>> the library. >>> When they want to upgrade to a new version, they should upgrade to the >>> new APIs as well. >>> >>> I don't think a weak policy is wise. We are a small project and >>> don't want to >>> maintain and test many versions of the libraries. To date we don't >>> have an >>> LTS policy and I think it would be good if we did not have to go >>> there. A >>> strong API stability statement means that users can pick up bug >>> fixes, new >>> platforms and even some new features without having to change [much] of >>> their application/system. Even if we define an LTS policy a stable >>> API policy >>> lowers the barrier to pick up that one new feature you need. >>> >>> ** Comments on the Zephyr policy: >>> >>> OpenAMP is a smaller project than Zephyr so I think we can simplify the >>> model a bit. >>> Certainly we want the API states of stable, deprecated, and removed. >>> I don't see any need to have two states before stable. >>> "Experimental" APIs should not be in the release branches, they >>> should be in >>> experimental branches or git repo forks. >>> You could say the same for "Unstable" but there are valid reasons to >>> include >>> it as well. >>> >>> The Zephyr policy says things stay in depreciated state for 2 >>> releases. Zephyr >>> makes releases ~ 2 times per year. So applications have to upgrade >>> versions >>> at least once a year to have any benefit from the policy. This seems >>> very >>> short to me. A 2 year depreciation stay seems more appropriate to me. >>> Another approach would be to specify a minimum and a maximum time in >>> deprecated state. Things that are easy to keep can stay for the max >>> time and >>> things that cause big headaches to maintain can stay for the minimum >>> time. >>> >>> ** Mechanism of compatibility >>> >>> As with the Zephyr policy we are focused on source level >>> compatibility. It is >>> acceptable if the user has to recompile his application to use the >>> new library >>> version. >>> >>> Maintaining a binary level API (more correctly an ABI) is a decent >>> amount of >>> extra work. If we do have Linux shared libraries that get commonly >>> used we >>> will need to look at this. However, I suggest we tackle that issues >>> as it arises. >>> (A static library does not have the same issue) >>> >>> **** Wire Protocol Stability: >>> >>> The wire protocol describes the interactions of two independent CPUs >>> in an >>> AMP system. The bar for maintaining compatibility at this level is much >>> higher. >>> >>> Some random thoughts/suggestions: >>> >>> (I am using "firmware" and "kernel" as stand-ins for the more general >>> cases >>> also) >>> >>> * break of compatibility of the protocol level should require TSC >>> approval >>> * New kernels should run old firmware >>> * New firmware that has extra features with new kernels should still >>> work >>> with old kernels if that is desired >>> * We need to know what properties of interaction are guaranteed vs just >>> how the current implementation works today >>> ** We need a protocol document >>> ** Until we do, we have to treat current UPSTREAM model as the defacto >>> standard >>> ** We can't really have protocol compatibility states until we have a >>> protocol >>> document >>> ** Anything currently only in vendor branches is considered Experimental >>> * New Protocol features and versions are best if they can be >>> discovered live >>> ** However manual opt-in by both parties is acceptable as a fallback >>> >>> Thanks, >>> Bill >>> >>> >>> --------------------------------------------------- >>> William A. Mills >>> Chief Technologist, Open Source >>> Texas Instruments, Processors >>> 20250 Century Blvd, Suit 300 >>> Germantown MD, 20874 >>> (work/mobile) +1-240-643-0836 >>> >>> >>> -- >>> Tsc mailing list >>> Tsc(a)lists.openampproject.org >>> https://lists.openampproject.org/mailman/listinfo/tsc > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy > the information in any medium. Thank you.

6 years

1
0
0 0

Re: [OA-Tsc] API and Wire protocol stability

by Grant Likely

Hi Bill, I don't have particularly strong opinions on the details of the policy. I do agree it is important to start with something (can be adjusted as the project goes along if necessary). Agree that being firm on wire protocol stability (and I think versioning) is very important, and you're thoughts on simplifying the Zepher model sound sensible. I would err toward not removing APIs, or moving them to a libcompat as wrappers to their replacements. The latter approach has a nice benefit of making it obvious when an API layer is no longer the preferred interface because the compat lib needs to be linked in. g. On 14/05/2020 08:22, Nathalie Chan King Choy via Tsc wrote: > Hi all, > > In today's TSC call, the suggestion was to continue this discussion over email > & then come to a decision during the July TSC call. > > Thanks & regards, > Nathalie > >> -----Original Message----- >> From: Tsc <tsc-bounces(a)lists.openampproject.org> On Behalf Of Mills, >> William via Tsc >> Sent: Saturday, April 18, 2020 8:41 AM >> To: tsc(a)lists.openampproject.org >> Subject: [OA-Tsc] API and Wire protocol stability >> >> CAUTION: This message has originated from an External Source. Please use >> proper judgment and caution when opening attachments, clicking links, or >> responding to this email. >> >> >> All, >> >> I have the action to write up thought on API stability. >> On 4/17 we added wire protocol stability to the list. >> There is also discussion of API homogeneity across different >> implementations and/or operating environments but that topic is out of >> scope for this discussion and I specifically opted out of leading that >> discussion. >> >> **** API Stability: >> >> For reference here is the Zephyr policy on API lifecycle: >> https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html >> >> ** Scope: >> >> The scope of the OpenAMP API lifecycle policy is mostly the libraries and >> supporting code owned by the project. >> Today that is primarily the open-amp and libmetal libraries but we expect >> that to expand in the future. >> >> Specifically out of scope would be the APIs internal to the Linux kernel. The >> Linux kernel has a famous "no stable api" policy. >> Probably also out of scope would be the kernel / user interface. This >> interface has a more stringent "don't break the user interface policy" than >> will be described here. >> >> Nothing prevents us from trying to apply our policies to the Linux kernel on a >> best effort basis but we need to understand the kernel's policies will >> override ours in a conflict. >> >> ** Why have a policy?: >> >> One possible policy is to have no policy or a weak one. Under such a policy, >> If someone is using the old API's, let then use the old version of the library. >> When they want to upgrade to a new version, they should upgrade to the >> new APIs as well. >> >> I don't think a weak policy is wise. We are a small project and don't want to >> maintain and test many versions of the libraries. To date we don't have an >> LTS policy and I think it would be good if we did not have to go there. A >> strong API stability statement means that users can pick up bug fixes, new >> platforms and even some new features without having to change [much] of >> their application/system. Even if we define an LTS policy a stable API policy >> lowers the barrier to pick up that one new feature you need. >> >> ** Comments on the Zephyr policy: >> >> OpenAMP is a smaller project than Zephyr so I think we can simplify the >> model a bit. >> Certainly we want the API states of stable, deprecated, and removed. >> I don't see any need to have two states before stable. >> "Experimental" APIs should not be in the release branches, they should be in >> experimental branches or git repo forks. >> You could say the same for "Unstable" but there are valid reasons to include >> it as well. >> >> The Zephyr policy says things stay in depreciated state for 2 releases. Zephyr >> makes releases ~ 2 times per year. So applications have to upgrade versions >> at least once a year to have any benefit from the policy. This seems very >> short to me. A 2 year depreciation stay seems more appropriate to me. >> Another approach would be to specify a minimum and a maximum time in >> deprecated state. Things that are easy to keep can stay for the max time and >> things that cause big headaches to maintain can stay for the minimum time. >> >> ** Mechanism of compatibility >> >> As with the Zephyr policy we are focused on source level compatibility. It is >> acceptable if the user has to recompile his application to use the new library >> version. >> >> Maintaining a binary level API (more correctly an ABI) is a decent amount of >> extra work. If we do have Linux shared libraries that get commonly used we >> will need to look at this. However, I suggest we tackle that issues as it arises. >> (A static library does not have the same issue) >> >> **** Wire Protocol Stability: >> >> The wire protocol describes the interactions of two independent CPUs in an >> AMP system. The bar for maintaining compatibility at this level is much >> higher. >> >> Some random thoughts/suggestions: >> >> (I am using "firmware" and "kernel" as stand-ins for the more general cases >> also) >> >> * break of compatibility of the protocol level should require TSC approval >> * New kernels should run old firmware >> * New firmware that has extra features with new kernels should still work >> with old kernels if that is desired >> * We need to know what properties of interaction are guaranteed vs just >> how the current implementation works today >> ** We need a protocol document >> ** Until we do, we have to treat current UPSTREAM model as the defacto >> standard >> ** We can't really have protocol compatibility states until we have a protocol >> document >> ** Anything currently only in vendor branches is considered Experimental >> * New Protocol features and versions are best if they can be discovered live >> ** However manual opt-in by both parties is acceptable as a fallback >> >> Thanks, >> Bill >> >> >> --------------------------------------------------- >> William A. Mills >> Chief Technologist, Open Source >> Texas Instruments, Processors >> 20250 Century Blvd, Suit 300 >> Germantown MD, 20874 >> (work/mobile) +1-240-643-0836 >> >> >> -- >> Tsc mailing list >> Tsc(a)lists.openampproject.org >> https://lists.openampproject.org/mailman/listinfo/tsc IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years

1
0
0 0

Re: [OA-Tsc] API and Wire protocol stability

by Nathalie Chan King Choy

Hi all, In today's TSC call, the suggestion was to continue this discussion over email & then come to a decision during the July TSC call. Thanks & regards, Nathalie > -----Original Message----- > From: Tsc <tsc-bounces(a)lists.openampproject.org> On Behalf Of Mills, > William via Tsc > Sent: Saturday, April 18, 2020 8:41 AM > To: tsc(a)lists.openampproject.org > Subject: [OA-Tsc] API and Wire protocol stability > > CAUTION: This message has originated from an External Source. Please use > proper judgment and caution when opening attachments, clicking links, or > responding to this email. > > > All, > > I have the action to write up thought on API stability. > On 4/17 we added wire protocol stability to the list. > There is also discussion of API homogeneity across different > implementations and/or operating environments but that topic is out of > scope for this discussion and I specifically opted out of leading that > discussion. > > **** API Stability: > > For reference here is the Zephyr policy on API lifecycle: > https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html > > ** Scope: > > The scope of the OpenAMP API lifecycle policy is mostly the libraries and > supporting code owned by the project. > Today that is primarily the open-amp and libmetal libraries but we expect > that to expand in the future. > > Specifically out of scope would be the APIs internal to the Linux kernel. The > Linux kernel has a famous "no stable api" policy. > Probably also out of scope would be the kernel / user interface. This > interface has a more stringent "don't break the user interface policy" than > will be described here. > > Nothing prevents us from trying to apply our policies to the Linux kernel on a > best effort basis but we need to understand the kernel's policies will > override ours in a conflict. > > ** Why have a policy?: > > One possible policy is to have no policy or a weak one. Under such a policy, > If someone is using the old API's, let then use the old version of the library. > When they want to upgrade to a new version, they should upgrade to the > new APIs as well. > > I don't think a weak policy is wise. We are a small project and don't want to > maintain and test many versions of the libraries. To date we don't have an > LTS policy and I think it would be good if we did not have to go there. A > strong API stability statement means that users can pick up bug fixes, new > platforms and even some new features without having to change [much] of > their application/system. Even if we define an LTS policy a stable API policy > lowers the barrier to pick up that one new feature you need. > > ** Comments on the Zephyr policy: > > OpenAMP is a smaller project than Zephyr so I think we can simplify the > model a bit. > Certainly we want the API states of stable, deprecated, and removed. > I don't see any need to have two states before stable. > "Experimental" APIs should not be in the release branches, they should be in > experimental branches or git repo forks. > You could say the same for "Unstable" but there are valid reasons to include > it as well. > > The Zephyr policy says things stay in depreciated state for 2 releases. Zephyr > makes releases ~ 2 times per year. So applications have to upgrade versions > at least once a year to have any benefit from the policy. This seems very > short to me. A 2 year depreciation stay seems more appropriate to me. > Another approach would be to specify a minimum and a maximum time in > deprecated state. Things that are easy to keep can stay for the max time and > things that cause big headaches to maintain can stay for the minimum time. > > ** Mechanism of compatibility > > As with the Zephyr policy we are focused on source level compatibility. It is > acceptable if the user has to recompile his application to use the new library > version. > > Maintaining a binary level API (more correctly an ABI) is a decent amount of > extra work. If we do have Linux shared libraries that get commonly used we > will need to look at this. However, I suggest we tackle that issues as it arises. > (A static library does not have the same issue) > > **** Wire Protocol Stability: > > The wire protocol describes the interactions of two independent CPUs in an > AMP system. The bar for maintaining compatibility at this level is much > higher. > > Some random thoughts/suggestions: > > (I am using "firmware" and "kernel" as stand-ins for the more general cases > also) > > * break of compatibility of the protocol level should require TSC approval > * New kernels should run old firmware > * New firmware that has extra features with new kernels should still work > with old kernels if that is desired > * We need to know what properties of interaction are guaranteed vs just > how the current implementation works today > ** We need a protocol document > ** Until we do, we have to treat current UPSTREAM model as the defacto > standard > ** We can't really have protocol compatibility states until we have a protocol > document > ** Anything currently only in vendor branches is considered Experimental > * New Protocol features and versions are best if they can be discovered live > ** However manual opt-in by both parties is acceptable as a fallback > > Thanks, > Bill > > > --------------------------------------------------- > William A. Mills > Chief Technologist, Open Source > Texas Instruments, Processors > 20250 Century Blvd, Suit 300 > Germantown MD, 20874 > (work/mobile) +1-240-643-0836 > > > -- > Tsc mailing list > Tsc(a)lists.openampproject.org > https://lists.openampproject.org/mailman/listinfo/tsc

6 years, 1 month

1
0
0 0

2020-05-12 OpenAMP TSC call notes & action items

by Nathalie Chan King Choy

Hi all, You can find the notes at: https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20200512 If you attended, please check & update the notes if you spot any errors or important omissions. Regarding one topic that came back up about Pull Requests, during the Feb TSC call, the official decision on that in Feb was: Will continue to use GitHub PR flow for contributions. Ed & Arnaud should also submit PRs for what they commit. So, basically no change to what was decided in Feb. Action items: * All: Continue API discussion by email * Stefano & Bruce: Document System DT & Lopper goals in OpenAMP Wiki at https://github.com/OpenAMP/open-amp/wiki/Future-Topics-for-System-Device-Tr… * Ed: Update the governance document to reflect what we're actually doing * Ed to do gap analysis of OpenAMP documentation & look at using Sphinx * Nathalie: Schedule next TSC call for July Decisions * Stefano officially voted in as the new leader of System DT OpenAMP working group * Informal: OpenAMP releases to continue at cadence of 2x/year until there is a need to change * Informal: Consider Sphinx for documentation instead of exhaustive analysis Thanks & regards, Nathalie C. Chan King Choy Program Manager focused on Open Source & Community

6 years, 1 month

1
0
0 0

Re: [OA-Tsc] API and Wire protocol stability

by Mills, William

resend -----Original Message----- From: Mills, William Sent: Saturday, April 18, 2020 11:35 AM To: tsc(a)lists.openampproject.org Subject: API and Wire protocol stability All, I have the action to write up thought on API stability. On 4/17 we added wire protocol stability to the list. There is also discussion of API homogeneity across different implementations and/or operating environments but that topic is out of scope for this discussion and I specifically opted out of leading that discussion. **** API Stability: For reference here is the Zephyr policy on API lifecycle: https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html ** Scope: The scope of the OpenAMP API lifecycle policy is mostly the libraries and supporting code owned by the project. Today that is primarily the open-amp and libmetal libraries but we expect that to expand in the future. Specifically out of scope would be the APIs internal to the Linux kernel. The Linux kernel has a famous "no stable api" policy. Probably also out of scope would be the kernel / user interface. This interface has a more stringent "don't break the user interface policy" than will be described here. Nothing prevents us from trying to apply our policies to the Linux kernel on a best effort basis but we need to understand the kernel's policies will override ours in a conflict. ** Why have a policy?: One possible policy is to have no policy or a weak one. Under such a policy, If someone is using the old API's, let then use the old version of the library. When they want to upgrade to a new version, they should upgrade to the new APIs as well. I don't think a weak policy is wise. We are a small project and don't want to maintain and test many versions of the libraries. To date we don't have an LTS policy and I think it would be good if we did not have to go there. A strong API stability statement means that users can pick up bug fixes, new platforms and even some new features without having to change [much] of their application/system. Even if we define an LTS policy a stable API policy lowers the barrier to pick up that one new feature you need. ** Comments on the Zephyr policy: OpenAMP is a smaller project than Zephyr so I think we can simplify the model a bit. Certainly we want the API states of stable, deprecated, and removed. I don't see any need to have two states before stable. "Experimental" APIs should not be in the release branches, they should be in experimental branches or git repo forks. You could say the same for "Unstable" but there are valid reasons to include it as well. The Zephyr policy says things stay in depreciated state for 2 releases. Zephyr makes releases ~ 2 times per year. So applications have to upgrade versions at least once a year to have any benefit from the policy. This seems very short to me. A 2 year depreciation stay seems more appropriate to me. Another approach would be to specify a minimum and a maximum time in deprecated state. Things that are easy to keep can stay for the max time and things that cause big headaches to maintain can stay for the minimum time. ** Mechanism of compatibility As with the Zephyr policy we are focused on source level compatibility. It is acceptable if the user has to recompile his application to use the new library version. Maintaining a binary level API (more correctly an ABI) is a decent amount of extra work. If we do have Linux shared libraries that get commonly used we will need to look at this. However, I suggest we tackle that issues as it arises. (A static library does not have the same issue) **** Wire Protocol Stability: The wire protocol describes the interactions of two independent CPUs in an AMP system. The bar for maintaining compatibility at this level is much higher. Some random thoughts/suggestions: (I am using "firmware" and "kernel" as stand-ins for the more general cases also) * break of compatibility of the protocol level should require TSC approval * New kernels should run old firmware * New firmware that has extra features with new kernels should still work with old kernels if that is desired * We need to know what properties of interaction are guaranteed vs just how the current implementation works today ** We need a protocol document ** Until we do, we have to treat current UPSTREAM model as the defacto standard ** We can't really have protocol compatibility states until we have a protocol document ** Anything currently only in vendor branches is considered Experimental * New Protocol features and versions are best if they can be discovered live ** However manual opt-in by both parties is acceptable as a fallback Thanks, Bill --------------------------------------------------- William A. Mills Chief Technologist, Open Source Texas Instruments, Processors 20250 Century Blvd, Suit 300 Germantown MD, 20874 (work/mobile) +1-240-643-0836

6 years, 1 month

1
0
0 0

Calling for agenda items - OpenAMP TSC May call

by Nathalie Chan King Choy

Hi all, Please send your suggestions for agenda items. I have collected so far: * Tomas, Maarten, Bill: Present working group goals/aspirations for next 6 months * Bill: API stability & Zephyr policy * Pick additional topics from Ed's Governance list. Options are: * Selection of new features for development * Testing * Documentation * Branching & tagging strategy * Release process Action items from last call are: * Maarten/Dan: document the goals/aspirations for App Services group in Future and Current work pages in OpenAMP Wiki * Tomas/Stefano/Bruce: document the goals/aspirations for System DT group in Future and Current work pages in OpenAMP Wiki * Bill M: document the goals/aspirations for OpenAMP-rp group in Future and Current work pages in OpenAMP Wiki * Bill M to write up the thoughts on API stability policy & point to the Zephyr policy * Bill M volunteers to drive the topic of wire protocol stability. Thanks & regards, Nathalie -----Original Appointment----- Subject: OpenAMP TSC - May call When: Tuesday, May 12, 2020 9:00 AM-10:00 AM (UTC-08:00) Pacific Time (US & Canada). Where: Zoom Hi all, Please join on Zoom: https://zoom.us/my/openampproject (If you need the meeting ID, it's 9031895760. I will email out the password directly to list members shortly before the call) The notes from the previous call (April 17) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20200417 For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community

6 years, 1 month

1
0
0 0

OpenAMP TSC - May call

by Nathalie Chan King Choy

Hi all, Please join on Zoom: https://zoom.us/my/openampproject (If you need the meeting ID, it's 9031895760. I will email out the password directly to list members shortly before the call) The notes from the previous call (April 17) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20200417 For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community

6 years, 1 month

1
0
0 0

2020-04-17 OpenAMP TSC call notes & action items

by Nathalie Chan King Choy

Hi all, You can find the notes at: https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20200417 If you attended, please check & update the notes if you spot any errors or important omissions. Action Items: * Nathalie: Put on board meeting agenda * We will vote at the next Board meeting to add to the charter at what interval we should re-pick the TSC chair. Suggestion is 1 year. * Make it official at Board meeting that working group proposes someone & TSC approves. Working group lead should attend TSC calls. * Maarten/Dan: document the goals/aspirations for App Services group in Future and Current work pages in OpenAMP Wiki * Tomas/Stefano/Bruce: document the goals/aspirations for System DT group in Future and Current work pages in OpenAMP Wiki * Bill M: document the goals/aspirations for OpenAMP-rp group in Future and Current work pages in OpenAMP Wiki * Bill M to write up the thoughts on API stability policy & point to the Zephyr policy * Bill M volunteers to drive the topic of wire protocol stability. Decisions * Tomas Evensen officially voted in as TSC chair Thanks & regards, Nathalie C. Chan King Choy Program Manager focused on Open Source & Community

6 years, 1 month

1
0
0 0

API and Wire protocol stability

by Mills, William

All, I have the action to write up thought on API stability. On 4/17 we added wire protocol stability to the list. There is also discussion of API homogeneity across different implementations and/or operating environments but that topic is out of scope for this discussion and I specifically opted out of leading that discussion. **** API Stability: For reference here is the Zephyr policy on API lifecycle: https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html ** Scope: The scope of the OpenAMP API lifecycle policy is mostly the libraries and supporting code owned by the project. Today that is primarily the open-amp and libmetal libraries but we expect that to expand in the future. Specifically out of scope would be the APIs internal to the Linux kernel. The Linux kernel has a famous "no stable api" policy. Probably also out of scope would be the kernel / user interface. This interface has a more stringent "don't break the user interface policy" than will be described here. Nothing prevents us from trying to apply our policies to the Linux kernel on a best effort basis but we need to understand the kernel's policies will override ours in a conflict. ** Why have a policy?: One possible policy is to have no policy or a weak one. Under such a policy, If someone is using the old API's, let then use the old version of the library. When they want to upgrade to a new version, they should upgrade to the new APIs as well. I don't think a weak policy is wise. We are a small project and don't want to maintain and test many versions of the libraries. To date we don't have an LTS policy and I think it would be good if we did not have to go there. A strong API stability statement means that users can pick up bug fixes, new platforms and even some new features without having to change [much] of their application/system. Even if we define an LTS policy a stable API policy lowers the barrier to pick up that one new feature you need. ** Comments on the Zephyr policy: OpenAMP is a smaller project than Zephyr so I think we can simplify the model a bit. Certainly we want the API states of stable, deprecated, and removed. I don't see any need to have two states before stable. "Experimental" APIs should not be in the release branches, they should be in experimental branches or git repo forks. You could say the same for "Unstable" but there are valid reasons to include it as well. The Zephyr policy says things stay in depreciated state for 2 releases. Zephyr makes releases ~ 2 times per year. So applications have to upgrade versions at least once a year to have any benefit from the policy. This seems very short to me. A 2 year depreciation stay seems more appropriate to me. Another approach would be to specify a minimum and a maximum time in deprecated state. Things that are easy to keep can stay for the max time and things that cause big headaches to maintain can stay for the minimum time. ** Mechanism of compatibility As with the Zephyr policy we are focused on source level compatibility. It is acceptable if the user has to recompile his application to use the new library version. Maintaining a binary level API (more correctly an ABI) is a decent amount of extra work. If we do have Linux shared libraries that get commonly used we will need to look at this. However, I suggest we tackle that issues as it arises. (A static library does not have the same issue) **** Wire Protocol Stability: The wire protocol describes the interactions of two independent CPUs in an AMP system. The bar for maintaining compatibility at this level is much higher. Some random thoughts/suggestions: (I am using "firmware" and "kernel" as stand-ins for the more general cases also) * break of compatibility of the protocol level should require TSC approval * New kernels should run old firmware * New firmware that has extra features with new kernels should still work with old kernels if that is desired * We need to know what properties of interaction are guaranteed vs just how the current implementation works today ** We need a protocol document ** Until we do, we have to treat current UPSTREAM model as the defacto standard ** We can't really have protocol compatibility states until we have a protocol document ** Anything currently only in vendor branches is considered Experimental * New Protocol features and versions are best if they can be discovered live ** However manual opt-in by both parties is acceptable as a fallback Thanks, Bill --------------------------------------------------- William A. Mills Chief Technologist, Open Source Texas Instruments, Processors 20250 Century Blvd, Suit 300 Germantown MD, 20874 (work/mobile) +1-240-643-0836

6 years, 1 month

1
0
0 0

Calling for agenda items - OpenAMP TSC April call

by Nathalie Chan King Choy

Hi all, Please send your suggestions for agenda items. I have collected so far: * Officially vote in a TSC chair * App-services update & looking for interest in porting PoC to Zephyr * Briefly: Start thinking about goals for next 6 months * MISRA & Functional Safety * Interface compatibility * Pick additional topics from Ed's Governance list. Options are: * Selection of new features for development * Testing * Documentation * Branching & tagging strategy * Release process Action items from last call are: * [DONE] Nathalie: Send out email to ask for TSC chair nominees * [DONE] Ed: Update push access to libmetal & libopenamp to just Ed & Arnaud * [DONE] Ed: Investigate OpenAMP GitHub ownership * [DONE] Nathalie: Ask Bill Fletcher about moving over GitHub repo for website to OpenAMP GitHub instead of OpenAMP Project * [DONE] Nathalie: Put MISRA & functional safety on agenda for next TSC call * [DONE] Nathalie: schedule next TSC call over email * [DONE] Nathalie: Check ahead for quorum for next call * Bill Mills: write a couple paragraphs on what the policy should be around interface compatibility & send out for review to list * All: Send suggestions for next TSC call agenda Thanks & regards, Nathalie -----Original Appointment----- Subject: OpenAMP TSC When: Friday, April 17, 2020 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada). Where: Zoom Hi all, Please join on Zoom: https://zoom.us/my/openampproject (If you need the meeting ID, it's 9031895760) Password will be sent in a separate email The notes from the previous call (Feb 20) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20200220 For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community

6 years, 2 months

1
0
0 0

OpenAMP TSC

by Nathalie Chan King Choy

Hi all, Please join on Zoom: https://zoom.us/my/openampproject (If you need the meeting ID, it's 9031895760) The notes from the previous call (Feb 20) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20200220 For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community

6 years, 2 months

1
0
0 0

Canceled: OpenAMP TSC - March call

by Nathalie Chan King Choy

Due to the conflict with Linaro Tech Days, this call will be postponed. Stay tuned for a new invitation.

6 years, 2 months

1
0
0 0

Re: [OA-Tsc] OpenAMP App-services

by Arnaud POULIQUEN

Hi all, 1. Concerning name service enhancement.: As mentioned Mathieu Poirier sent a patch that allows to have more dynamic name service usage. https://lkml.org/lkml/2020/2/12/1083 (this patch is waiting maintainer review) Looking into OpenAMP code, seems that this already works like that, but need to be confirmed… 1. Concerning OpenAMP integration in Zephyr. Current status in last Zephyr release is : * OpenAMP release v2018.10 integrated * A sample exists demonstrate communication on an NXP lpcxpresso54114 board between 2 MCUs running Zephyr https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/subsys/ipc… * A Nordic BT HCI driver relying on rpmg https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/bluetooth/… * FYI this driver trigged some discussions around a generic demon to parse the RPMsg message out of drivers, in a dedicated thread. In addition Pull requests on going that could be used to implement the OpenAMP demon. * Sample based on a resource table: https://github.com/zephyrproject-rtos/zephyr/pull/16985 * OpenAMP V2020.01.0 https://github.com/zephyrproject-rtos/open-amp/pull/4 * Libmetal v2020.01.0 https://github.com/zephyrproject-rtos/libmetal/pull/1 Regards Arnaud -----Original Appointment----- From: Koning, Maarten <maarten.koning(a)windriver.com> Sent: mercredi 29 janvier 2020 16:04 To: Koning, Maarten; App-services Cc: OpenAMP TSC; Grant Likely; Nathalie Chan King Choy; nathalie-ckc(a)kestrel-omnitech.com; Bruce Ashfield; Ed T. Mooring; Mills, William; Milea, Danut Gabriel (Danut); Tony McDowell; Loic PALLARDY; matt1394(a)gmail.com; Anoop Nair Subject: [OA-Tsc] OpenAMP App-services When: lundi 23 mars 2020 11:00-12:00 (UTC-05:00) Eastern Time (US & Canada). Where: zoom as below Agenda update: We will spend the time discussing the current list of activities the group needs to progress on. This group will hopefully be able to do a divide-and-conquer to scale progress. Please come mentally prepared to sign-up to some of the group’s activities listed below! 😉 Group Activities: 1. app-services wiki – need someone to setup and prime 2. app-services git repo – need someone to setup and prime 3. app-services high-level use cases – need someone to be wiki editor on this. Also, call for contributions. 4. IPC APIs for app services – need someone to be wiki editor on this. Also, call for contributions / proposals. - name service API: registration, lookup, scope - sockets API: connection-oriented byte-stream/messages, connection-less messages - send-receive-reply API - publish-subscribe API - remote-procedure call API 5. OpenAMP app-services daemon - Dan Milea voluntold, for isled daemon (Linux & VxWorks) - will update on plan to open-source into nascent app-service git repo - need someone to collaborate with on Zephyr implementation Agenda: - review of above activities and poll of volunteers who wish to collaborate on each. - next steps ------ Click here: https://windriver.zoom.us/j/8843914172 (meeting ID: 884-391-4172) US (Toll-free) +1 877 853 5247 US (Toll-free) +1 888 788 0099 Canada (Toll-free) +1 855 703 8985 France (Toll-free) +33 8 0508 2588 Germany (Toll-free) +49 800 724 3138 Download the Client (and Outlook Plug in): https://zoom.us/download Getting Started Guide: https://support.zoom.us/hc/en-us/categories/200101697 *** full list of country dial-ins below *** Algeria (Fee-based Toll) +213 98 24 02 675 Argentina (Toll-free) +54 822 345 9889 Australia (Toll-free) +61 18 0089 3423 Austria (Toll-free) +43 800 802 588 Bahamas (Toll-free) 1800 389 0808 Bahrain (Toll-free) +973 800 198 33 Belgium (Toll-free) +32 800 267 88 Bermuda (Toll-free) +1 866 237 6875 Bolivia (Toll-free) 800 100 560 Bosnia and Herzegovina (Toll-free) 0800 828 50 Brazil (Toll-free) +55 800 878 3108 Bulgaria (Toll-free) 00800 111 3251 Cambodia (Toll-free) +855 1800 201 503 Canada (Toll-free) +1 855 703 8985 Cayman Islands (Fee-based Toll) +1 345 769 1930 Chile (Toll-free) 800 914 125 China (Toll-free) 400 616 8835 China (Toll-free) 400 669 9381 China (Fee-based Toll) +86 (0)10 53876330 China (Fee-based Toll) +86 (0)10 87833177 Colombia (Toll-free) 1 800 518 4301 Costa Rica (Fee-based Toll) +506 4000 3843 Croatia (Toll-free) +385 800 200 588 Cyprus (Toll-free) +357 800 773 38 Czech Republic (Toll-free) +420 828 848 888 Denmark (Toll-free) +45 80 82 02 88 Dominican Republic (Toll-free) 1 800 751 9718 Ecuador (Toll-free) 1800 000 785 Egypt (Toll-free) 0800 000 9608 Fiji (Toll-free) 0080 02 592 Finland (Toll-free) +358 800 102 188 France (Toll-free) +33 8 0508 2588 Germany (Toll-free) +49 800 724 3138 Ghana (Toll-free) +233 30 708 4676 Greece (Toll-free) +30 800 848 1188 Guatemala (Toll-free) 1800 3000 161 Honduras (Toll-free) 800 2791 9494 Hong Kong, China (Toll-free) 800 906 780 Hungary (Toll-free) +36 800 881 88 Iceland (Toll-free) 0080 07 473 India (Toll-free) 000 800 001 4002 India (Toll-free) 1 800 102 9182 India (Toll-free) 1 800 267 2722 India (Fee-based Toll) +91 22 48 798 004 India (Fee-based Toll) +91 22 62 192 563 India (Fee-based Toll) +91 22 71 279 525 India (Fee-based Toll) +91 80 71 279 440 Indonesia (Fee-based Toll) +62 21 2188 9017 Ireland (Toll-free) +353 1800 817 388 Israel (Toll-free) +972 180 122 7228 Italy (Toll-free) +39 800 596 788 Jamaica (Toll-free) +1 800 491 6523 Jamaica (Fee-based Toll) +1 876 633 1687 Japan (Toll-free) +81 (0) 800 100 5040 Kazakhstan (Fee-based Toll) +7 727 312 2408 Kenya (Toll-free) 800 733 310 Kuwait (Fee-based Toll) +965 2206 9157 Latvia (Toll-free) 8000 0281 Lithuania (Toll-free) 8 800 3 03 19 Luxembourg (Toll-free) +352 800 810 88 Macau, China (Toll-free) 0 800 191 Macau, China (Fee-based Toll) +853 6262 1604 Macedonia [FYROM] (Toll-free) 0800 904 59 Malaysia (Toll-free) 1 800 818 425 Malta (Toll-free) 800 62714 Mexico (Toll-free) +52 1 800 733 4118 Netherlands (Toll-free) +31 800 220 0040 New Zealand (Toll-free) +64 800 002 260 Nigeria (Toll-free) +234 (0) 708 060 1822 Nigeria (Fee-based Toll) +234 1227 8806 Norway (Toll-free) +47 800 248 88 Oman (Toll-free) 800 74201 Pakistan (Fee-based Toll) +92 21 3879 9843 Panama (Toll-free) +507 800 0558 Paraguay (Toll-free) 0098 0011 0288 Peru (Toll-free) 800 78743 Philippines (Toll-free) +63 1 800 1110 2219 Philippines (Fee-based Toll) +63 92 3099 0478 Poland (Toll-free) 00 800 321 1464 Portugal (Toll-free) +351 800 180 888 Puerto Rico (Toll-free) +1 800 239 1922 Qatar (Toll-free) 00 800 100363 Romania (Toll-free) 0 800 672 631 Russia (Toll-free) +7 800 100 6938 Saudi Arabia (Toll-free) +966 800 811 0528 Saudi Arabia (Toll-free) 800 850 0304 Serbia (Toll-free) 0 800 500 702 Singapore (Toll-free) 800 852 6054 Slovakia (Toll-free) 0 800 005 424 Slovenia (Toll-free) +386 80 488 840 South Africa (Toll-free) +27 800 008 728 South Africa (Toll-free) +27 800 064 584 South Africa (Toll-free) +27 800 990 680 South Korea (Toll-free) +82 80 822 0250 Spain (Toll-free) +34 900 839 088 Sri Lanka (Fee-based Toll) +94 7 2091 0374 Sweden (Toll-free) +46 20 889 860 Switzerland (Toll-free) +41 (0) 800 002 622 Taiwan, China (Fee-based Toll) +886 (2) 7741 7473 Thailand (Toll-free) 1 800 012 275 Thailand (Fee-based Toll) +66 2018 2486 Thailand (Fee-based Toll) +66 60 003 5790 Trinidad and Tobago (Fee-based Toll) +1 868 224 5838 Tunisia (Fee-based Toll) +216 (0) 31 399 163 Turkey (Toll-free) +90 811 213 0011 US (Toll-free) +1 877 853 5247 US (Toll-free) +1 888 788 0099 Uganda (Fee-based Toll) +256 206 300 097 Ukraine (Toll-free) 0 800 501567 United Arab Emirates (Toll-free) +971 800 035 704 239 United Arab Emirates (Toll-free) +971 800 035 704 555 United Kingdom (Toll-free) +44 800 031 5717 Uruguay (Toll-free) 0004 054 189 Uzbekistan (Toll-free) +998 800 120 1235 Venezuela (Toll-free) 0 800 100 5564 Vietnam (Fee-based Toll) +84 28 4458 2373 Zimbabwe (Fee-based Toll) +263 864 404 1086

6 years, 2 months

1
0
0 0

OpenAMP App-services

by Koning, Maarten

Agenda update: We will spend the time discussing the current list of activities the group needs to progress on. This group will hopefully be able to do a divide-and-conquer to scale progress. Please come mentally prepared to sign-up to some of the group’s activities listed below! 😉 Group Activities: 1. app-services wiki – need someone to setup and prime 2. app-services git repo – need someone to setup and prime 3. app-services high-level use cases – need someone to be wiki editor on this. Also, call for contributions. 4. IPC APIs for app services – need someone to be wiki editor on this. Also, call for contributions / proposals. - name service API: registration, lookup, scope - sockets API: connection-oriented byte-stream/messages, connection-less messages - send-receive-reply API - publish-subscribe API - remote-procedure call API 5. OpenAMP app-services daemon - Dan Milea voluntold, for isled daemon (Linux & VxWorks) - will update on plan to open-source into nascent app-service git repo - need someone to collaborate with on Zephyr implementation Agenda: - review of above activities and poll of volunteers who wish to collaborate on each. - next steps ------ Click here: https://windriver.zoom.us/j/8843914172 (meeting ID: 884-391-4172) US (Toll-free) +1 877 853 5247 US (Toll-free) +1 888 788 0099 Canada (Toll-free) +1 855 703 8985 France (Toll-free) +33 8 0508 2588 Germany (Toll-free) +49 800 724 3138 Download the Client (and Outlook Plug in): https://zoom.us/download Getting Started Guide: https://support.zoom.us/hc/en-us/categories/200101697 *** full list of country dial-ins below *** Algeria (Fee-based Toll) +213 98 24 02 675 Argentina (Toll-free) +54 822 345 9889 Australia (Toll-free) +61 18 0089 3423 Austria (Toll-free) +43 800 802 588 Bahamas (Toll-free) 1800 389 0808 Bahrain (Toll-free) +973 800 198 33 Belgium (Toll-free) +32 800 267 88 Bermuda (Toll-free) +1 866 237 6875 Bolivia (Toll-free) 800 100 560 Bosnia and Herzegovina (Toll-free) 0800 828 50 Brazil (Toll-free) +55 800 878 3108 Bulgaria (Toll-free) 00800 111 3251 Cambodia (Toll-free) +855 1800 201 503 Canada (Toll-free) +1 855 703 8985 Cayman Islands (Fee-based Toll) +1 345 769 1930 Chile (Toll-free) 800 914 125 China (Toll-free) 400 616 8835 China (Toll-free) 400 669 9381 China (Fee-based Toll) +86 (0)10 53876330 China (Fee-based Toll) +86 (0)10 87833177 Colombia (Toll-free) 1 800 518 4301 Costa Rica (Fee-based Toll) +506 4000 3843 Croatia (Toll-free) +385 800 200 588 Cyprus (Toll-free) +357 800 773 38 Czech Republic (Toll-free) +420 828 848 888 Denmark (Toll-free) +45 80 82 02 88 Dominican Republic (Toll-free) 1 800 751 9718 Ecuador (Toll-free) 1800 000 785 Egypt (Toll-free) 0800 000 9608 Fiji (Toll-free) 0080 02 592 Finland (Toll-free) +358 800 102 188 France (Toll-free) +33 8 0508 2588 Germany (Toll-free) +49 800 724 3138 Ghana (Toll-free) +233 30 708 4676 Greece (Toll-free) +30 800 848 1188 Guatemala (Toll-free) 1800 3000 161 Honduras (Toll-free) 800 2791 9494 Hong Kong, China (Toll-free) 800 906 780 Hungary (Toll-free) +36 800 881 88 Iceland (Toll-free) 0080 07 473 India (Toll-free) 000 800 001 4002 India (Toll-free) 1 800 102 9182 India (Toll-free) 1 800 267 2722 India (Fee-based Toll) +91 22 48 798 004 India (Fee-based Toll) +91 22 62 192 563 India (Fee-based Toll) +91 22 71 279 525 India (Fee-based Toll) +91 80 71 279 440 Indonesia (Fee-based Toll) +62 21 2188 9017 Ireland (Toll-free) +353 1800 817 388 Israel (Toll-free) +972 180 122 7228 Italy (Toll-free) +39 800 596 788 Jamaica (Toll-free) +1 800 491 6523 Jamaica (Fee-based Toll) +1 876 633 1687 Japan (Toll-free) +81 (0) 800 100 5040 Kazakhstan (Fee-based Toll) +7 727 312 2408 Kenya (Toll-free) 800 733 310 Kuwait (Fee-based Toll) +965 2206 9157 Latvia (Toll-free) 8000 0281 Lithuania (Toll-free) 8 800 3 03 19 Luxembourg (Toll-free) +352 800 810 88 Macau, China (Toll-free) 0 800 191 Macau, China (Fee-based Toll) +853 6262 1604 Macedonia [FYROM] (Toll-free) 0800 904 59 Malaysia (Toll-free) 1 800 818 425 Malta (Toll-free) 800 62714 Mexico (Toll-free) +52 1 800 733 4118 Netherlands (Toll-free) +31 800 220 0040 New Zealand (Toll-free) +64 800 002 260 Nigeria (Toll-free) +234 (0) 708 060 1822 Nigeria (Fee-based Toll) +234 1227 8806 Norway (Toll-free) +47 800 248 88 Oman (Toll-free) 800 74201 Pakistan (Fee-based Toll) +92 21 3879 9843 Panama (Toll-free) +507 800 0558 Paraguay (Toll-free) 0098 0011 0288 Peru (Toll-free) 800 78743 Philippines (Toll-free) +63 1 800 1110 2219 Philippines (Fee-based Toll) +63 92 3099 0478 Poland (Toll-free) 00 800 321 1464 Portugal (Toll-free) +351 800 180 888 Puerto Rico (Toll-free) +1 800 239 1922 Qatar (Toll-free) 00 800 100363 Romania (Toll-free) 0 800 672 631 Russia (Toll-free) +7 800 100 6938 Saudi Arabia (Toll-free) +966 800 811 0528 Saudi Arabia (Toll-free) 800 850 0304 Serbia (Toll-free) 0 800 500 702 Singapore (Toll-free) 800 852 6054 Slovakia (Toll-free) 0 800 005 424 Slovenia (Toll-free) +386 80 488 840 South Africa (Toll-free) +27 800 008 728 South Africa (Toll-free) +27 800 064 584 South Africa (Toll-free) +27 800 990 680 South Korea (Toll-free) +82 80 822 0250 Spain (Toll-free) +34 900 839 088 Sri Lanka (Fee-based Toll) +94 7 2091 0374 Sweden (Toll-free) +46 20 889 860 Switzerland (Toll-free) +41 (0) 800 002 622 Taiwan, China (Fee-based Toll) +886 (2) 7741 7473 Thailand (Toll-free) 1 800 012 275 Thailand (Fee-based Toll) +66 2018 2486 Thailand (Fee-based Toll) +66 60 003 5790 Trinidad and Tobago (Fee-based Toll) +1 868 224 5838 Tunisia (Fee-based Toll) +216 (0) 31 399 163 Turkey (Toll-free) +90 811 213 0011 US (Toll-free) +1 877 853 5247 US (Toll-free) +1 888 788 0099 Uganda (Fee-based Toll) +256 206 300 097 Ukraine (Toll-free) 0 800 501567 United Arab Emirates (Toll-free) +971 800 035 704 239 United Arab Emirates (Toll-free) +971 800 035 704 555 United Kingdom (Toll-free) +44 800 031 5717 Uruguay (Toll-free) 0004 054 189 Uzbekistan (Toll-free) +998 800 120 1235 Venezuela (Toll-free) 0 800 100 5564 Vietnam (Fee-based Toll) +84 28 4458 2373 Zimbabwe (Fee-based Toll) +263 864 404 1086

6 years, 2 months

1
0
0 0

Calling for agenda items: OpenAMP TSC - March call

by Nathalie Chan King Choy

Hi all, Please send your suggestions for agenda items. I have collected so far: * Officially vote in a TSC chair (so far the only nominee is Tomas) * MISRA & Functional Safety * Interface compatibility * Pick additional topics from Ed's Governance list. Options are: * Selection of new features for development * Testing * Documentation * Branching & tagging strategy * Release process Action items from last call are: * [DONE] Nathalie: Send out email to ask for TSC chair nominees * [DONE] Ed: Update push access to libmetal & libopenamp to just Ed & Arnaud * [DONE] Ed: Investigate OpenAMP GitHub ownership * [DONE] Nathalie: Ask Bill Fletcher about moving over GitHub repo for website to OpenAMP GitHub instead of OpenAMP Project * [DONE] Nathalie: Put MISRA & functional safety on agenda for next TSC call * [DONE] Nathalie: schedule next TSC call over email * [DONE] Nathalie: Check ahead for quorum for next call * Bill Mills: write a couple paragraphs on what the policy should be around interface compatibility & send out for review to list * All: Send suggestions for next TSC call agenda Thanks & regards, Nathalie -----Original Appointment----- From: Nathalie Chan King Choy Sent: Tuesday, March 10, 2020 11:52 AM To: Nathalie Chan King Choy; tsc(a)lists.openampproject.org Cc: Hancock, Jeffrey; nathalie-ckc(a)kestrel-omnitech.com; Bruce Ashfield; Vicky Janicki; Mills, William; Mathieu Poirier; Koning, Maarten; Loic PALLARDY; Ed T. Mooring; Glaropoulos, Ioannis; Clément Leger; Tony McDowell; Felix Burton; matt1394(a)gmail.com; Vincent Chardon; Wesley Skeffington Subject: OpenAMP TSC - March call When: Wednesday, March 25, 2020 9:00 AM-10:00 AM (UTC-08:00) Pacific Time (US & Canada). Where: zoom Hi all, Please join on Zoom: https://zoom.us/my/openampproject (If you need the meeting ID, it's 9031895760) The notes from the previous call (Feb 20) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20200220 For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Project Manager focused on Open Source and Community

6 years, 2 months

1
0
0 0

OpenAMP TSC - March call

by Nathalie Chan King Choy

Hi all, Please join on Zoom: https://zoom.us/my/openampproject (If you need the meeting ID, it's 9031895760) The notes from the previous call (Feb 20) can be found at https://github.com/OpenAMP/open-amp/wiki/TSC-Meeting-Notes-2020#20200220 For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/tsc Best regards, Nathalie C. Chan King Choy Project Manager focused on Open Source and Community

6 years, 3 months

1
0
0 0

OpenAMP App-services

by Koning, Maarten

Topics: - app-services wiki - app-services git repo - app-service use cases - numbering plans for interconnects & OS instances - Next steps ------ Click here: https://windriver.zoom.us/j/8843914172 (meeting ID: 884-391-4172) US (Toll-free) +1 877 853 5247 US (Toll-free) +1 888 788 0099 Canada (Toll-free) +1 855 703 8985 France (Toll-free) +33 8 0508 2588 Germany (Toll-free) +49 800 724 3138 Download the Client (and Outlook Plug in): https://zoom.us/download Getting Started Guide: https://support.zoom.us/hc/en-us/categories/200101697 *** full list of country dial-ins below *** Algeria (Fee-based Toll) +213 98 24 02 675 Argentina (Toll-free) +54 822 345 9889 Australia (Toll-free) +61 18 0089 3423 Austria (Toll-free) +43 800 802 588 Bahamas (Toll-free) 1800 389 0808 Bahrain (Toll-free) +973 800 198 33 Belgium (Toll-free) +32 800 267 88 Bermuda (Toll-free) +1 866 237 6875 Bolivia (Toll-free) 800 100 560 Bosnia and Herzegovina (Toll-free) 0800 828 50 Brazil (Toll-free) +55 800 878 3108 Bulgaria (Toll-free) 00800 111 3251 Cambodia (Toll-free) +855 1800 201 503 Canada (Toll-free) +1 855 703 8985 Cayman Islands (Fee-based Toll) +1 345 769 1930 Chile (Toll-free) 800 914 125 China (Toll-free) 400 616 8835 China (Toll-free) 400 669 9381 China (Fee-based Toll) +86 (0)10 53876330 China (Fee-based Toll) +86 (0)10 87833177 Colombia (Toll-free) 1 800 518 4301 Costa Rica (Fee-based Toll) +506 4000 3843 Croatia (Toll-free) +385 800 200 588 Cyprus (Toll-free) +357 800 773 38 Czech Republic (Toll-free) +420 828 848 888 Denmark (Toll-free) +45 80 82 02 88 Dominican Republic (Toll-free) 1 800 751 9718 Ecuador (Toll-free) 1800 000 785 Egypt (Toll-free) 0800 000 9608 Fiji (Toll-free) 0080 02 592 Finland (Toll-free) +358 800 102 188 France (Toll-free) +33 8 0508 2588 Germany (Toll-free) +49 800 724 3138 Ghana (Toll-free) +233 30 708 4676 Greece (Toll-free) +30 800 848 1188 Guatemala (Toll-free) 1800 3000 161 Honduras (Toll-free) 800 2791 9494 Hong Kong, China (Toll-free) 800 906 780 Hungary (Toll-free) +36 800 881 88 Iceland (Toll-free) 0080 07 473 India (Toll-free) 000 800 001 4002 India (Toll-free) 1 800 102 9182 India (Toll-free) 1 800 267 2722 India (Fee-based Toll) +91 22 48 798 004 India (Fee-based Toll) +91 22 62 192 563 India (Fee-based Toll) +91 22 71 279 525 India (Fee-based Toll) +91 80 71 279 440 Indonesia (Fee-based Toll) +62 21 2188 9017 Ireland (Toll-free) +353 1800 817 388 Israel (Toll-free) +972 180 122 7228 Italy (Toll-free) +39 800 596 788 Jamaica (Toll-free) +1 800 491 6523 Jamaica (Fee-based Toll) +1 876 633 1687 Japan (Toll-free) +81 (0) 800 100 5040 Kazakhstan (Fee-based Toll) +7 727 312 2408 Kenya (Toll-free) 800 733 310 Kuwait (Fee-based Toll) +965 2206 9157 Latvia (Toll-free) 8000 0281 Lithuania (Toll-free) 8 800 3 03 19 Luxembourg (Toll-free) +352 800 810 88 Macau, China (Toll-free) 0 800 191 Macau, China (Fee-based Toll) +853 6262 1604 Macedonia [FYROM] (Toll-free) 0800 904 59 Malaysia (Toll-free) 1 800 818 425 Malta (Toll-free) 800 62714 Mexico (Toll-free) +52 1 800 733 4118 Netherlands (Toll-free) +31 800 220 0040 New Zealand (Toll-free) +64 800 002 260 Nigeria (Toll-free) +234 (0) 708 060 1822 Nigeria (Fee-based Toll) +234 1227 8806 Norway (Toll-free) +47 800 248 88 Oman (Toll-free) 800 74201 Pakistan (Fee-based Toll) +92 21 3879 9843 Panama (Toll-free) +507 800 0558 Paraguay (Toll-free) 0098 0011 0288 Peru (Toll-free) 800 78743 Philippines (Toll-free) +63 1 800 1110 2219 Philippines (Fee-based Toll) +63 92 3099 0478 Poland (Toll-free) 00 800 321 1464 Portugal (Toll-free) +351 800 180 888 Puerto Rico (Toll-free) +1 800 239 1922 Qatar (Toll-free) 00 800 100363 Romania (Toll-free) 0 800 672 631 Russia (Toll-free) +7 800 100 6938 Saudi Arabia (Toll-free) +966 800 811 0528 Saudi Arabia (Toll-free) 800 850 0304 Serbia (Toll-free) 0 800 500 702 Singapore (Toll-free) 800 852 6054 Slovakia (Toll-free) 0 800 005 424 Slovenia (Toll-free) +386 80 488 840 South Africa (Toll-free) +27 800 008 728 South Africa (Toll-free) +27 800 064 584 South Africa (Toll-free) +27 800 990 680 South Korea (Toll-free) +82 80 822 0250 Spain (Toll-free) +34 900 839 088 Sri Lanka (Fee-based Toll) +94 7 2091 0374 Sweden (Toll-free) +46 20 889 860 Switzerland (Toll-free) +41 (0) 800 002 622 Taiwan, China (Fee-based Toll) +886 (2) 7741 7473 Thailand (Toll-free) 1 800 012 275 Thailand (Fee-based Toll) +66 2018 2486 Thailand (Fee-based Toll) +66 60 003 5790 Trinidad and Tobago (Fee-based Toll) +1 868 224 5838 Tunisia (Fee-based Toll) +216 (0) 31 399 163 Turkey (Toll-free) +90 811 213 0011 US (Toll-free) +1 877 853 5247 US (Toll-free) +1 888 788 0099 Uganda (Fee-based Toll) +256 206 300 097 Ukraine (Toll-free) 0 800 501567 United Arab Emirates (Toll-free) +971 800 035 704 239 United Arab Emirates (Toll-free) +971 800 035 704 555 United Kingdom (Toll-free) +44 800 031 5717 Uruguay (Toll-free) 0004 054 189 Uzbekistan (Toll-free) +998 800 120 1235 Venezuela (Toll-free) 0 800 100 5564 Vietnam (Fee-based Toll) +84 28 4458 2373 Zimbabwe (Fee-based Toll) +263 864 404 1086

6 years, 3 months

1
0
0 0

Re: [OA-Tsc] Please send any nominations for OpenAMP TSC Chair

by Nathalie Chan King Choy

Hi Bill, > (I had to manually add the tsc back to the "to:" list even after I double checked that I hit "reply-all". Is this an outlook thing or a mail list setup thing?) Seems to be Outlook: I have both my Xilinx & Gsuite emails subscribed to this list for testing for quirks. When I hit "reply all" in Outlook, it just replies to you & Grant. When I did that from this Gsuite address, it includes the TSC list. Thanks & regards, Nathalie On Fri, Feb 21, 2020 at 8:52 AM Mills, William via Tsc < tsc(a)lists.openampproject.org> wrote: > TI seconds Tomas. > > (I had to manually add the tsc back to the "to:" list even after I double > checked that I hit "reply-all". Is this an outlook thing or a mail list > setup thing?) > > Bill > > -----Original Message----- > From: Tsc [mailto:tsc-bounces@lists.openampproject.org] On Behalf Of > Grant Likely via Tsc > Sent: Friday, February 21, 2020 6:16 AM > To: tsc(a)lists.openampproject.org > Subject: Re: [OA-Tsc] Please send any nominations for OpenAMP TSC Chair > > Arm would like to nominate Tomas. > > g. > > On 20/02/2020 18:59, Nathalie Chan King Choy via Tsc wrote: > > Hi all, > > > > Tomas has been acting chair for the OpenAMP TSC. We have not formally > > voted in a TSC chair. Tomas is happy to continue, or pass the torch on > > to a new TSC chair. > > > > Please send your nominations to the list by March 5^th , 2020. > > > > Thanks & regards, > > > > Nathalie C. Chan King Choy > > > > Project Manager focused on Open Source & Community > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > -- > Tsc mailing list > Tsc(a)lists.openampproject.org > https://lists.openampproject.org/mailman/listinfo/tsc > -- > Tsc mailing list > Tsc(a)lists.openampproject.org > https://lists.openampproject.org/mailman/listinfo/tsc >

6 years, 3 months

1
0
0 0

Re: [OA-Tsc] Please send any nominations for OpenAMP TSC Chair

by Mills, William

TI seconds Tomas. (I had to manually add the tsc back to the "to:" list even after I double checked that I hit "reply-all". Is this an outlook thing or a mail list setup thing?) Bill -----Original Message----- From: Tsc [mailto:tsc-bounces@lists.openampproject.org] On Behalf Of Grant Likely via Tsc Sent: Friday, February 21, 2020 6:16 AM To: tsc(a)lists.openampproject.org Subject: Re: [OA-Tsc] Please send any nominations for OpenAMP TSC Chair Arm would like to nominate Tomas. g. On 20/02/2020 18:59, Nathalie Chan King Choy via Tsc wrote: > Hi all, > > Tomas has been acting chair for the OpenAMP TSC. We have not formally > voted in a TSC chair. Tomas is happy to continue, or pass the torch on > to a new TSC chair. > > Please send your nominations to the list by March 5^th , 2020. > > Thanks & regards, > > Nathalie C. Chan King Choy > > Project Manager focused on Open Source & Community > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Tsc mailing list Tsc(a)lists.openampproject.org https://lists.openampproject.org/mailman/listinfo/tsc

6 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

Tsc