- Tsc - lists.openampproject.org

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

3 years, 7 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

3 years, 8 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.

3 years, 9 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

3 years, 9 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

3 years, 10 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

3 years, 10 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.

3 years, 11 months

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 >

3 years, 11 months

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

3 years, 11 months

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

3 years, 11 months

1
0
0 0

2024

2023

2022

2021

2020

2019

Tsc