TSC Meeting Notes 2020 - OpenAMP/open-amp GitHub Wiki
- Bill Mills (Linaro) - voting member
- Ioannis Glaropoulos (Nordic) - voting member
- Loic Pallardy (ST) - voting member
- Maarten Koning (Wind River) - voting member
- Poonam Aggrwal (NXP) - voting member
- Tomas Evensen (Xilinx) - voting member
- Arnaud Pouliquen
- Bruce Ashfield
- Ed Mooring
- Nathalie Chan King Choy
- 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?
- 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
- (informal) Might be good to combine with OP-TEE in looking at the MISRA question
- Consensus & conflict resolution
- Documentation
- Many end users get OpenAMP via an OS or Semi vendor
- Protocol & architecture descriptions would be good for project to own
- Would be good to put into a modern framework
- Then could update for what we do today
- Want to avoid paying for a long learning curve & want someone very technical who will be able to be productive fast.
- Could someone set up the framework, help with outline, get us on the right path. Then could get individual contributors.
- Yocto Project's doc writer passed away
- 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
- Want it to be Engineer-friendly to contribute: Markdown & Sphinx
- Does your company have any OpenAMP documentation that we can open source? Put it someplace & send us a link
- When to revisit MISRA question?
- OP-TEE starting to ask the same Q
- Will look at Xen, Zephyr & Trusted Firmware
- TF has already started running their code through MISRA
- Might be good to combine with OP-TEE in looking at the MISRA question
- Bill M can start a thread with TF, OP-TEE & OpenAMP TSC about MISRA
- OP-TEE starting to ask the same Q
- Nathalie: Schedule next call for February
- Tomas Evensen (Xilinx) - voting member
- Maarten Koning (Wind River) - voting member
- Vicky Janicki (Linaro) - voting member
- Ioannis Glaropoulos (Nordic) - voting member
- Etsam Anjum (MGC) - voting member
- Poonam Aggrwal (NXP) - voting member
- Grant Likely (Arm) - voting member
- Jeffrey Hancock (MGC) - alternate voting member
- Bruce Ashfield
- Mathieu Poirier
- Stefano Stabellini
- Arnaud Pouliquen
- Ed Mooring
- Nathalie Chan King Choy
- What are the working groups’ goals for the next 6 months?
- Do those goals require any budget $? (e.g. tools licenses)
- Governance: Stefano to present how Xen Project makes decisions and resolves conflicts
- (as time allows) Governance: Discuss the next open item(s) on https://github.com/OpenAMP/website/blob/master/_pages/governance.md
- 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
- Next call in December
- Goals for next 6 months
- OpenAMP RP
- continued upstreaming of vendor patches
- name service extension finalization
- End point announces itself w/ name service announcement
- Want to have wild-carding so driver can bind to
- Complication: Name service also being used by vhost side of RPMsg.
- Detach model upstream
- Possible protocol changes to support this fully
- Right now in 5.9 cycle have capability to attach to remote processor core instead of booting it (application side). This only half of the whole feature.
- The other half is when we have attached & want to stop it or that remote processor is crashing. How do we recover the system? Should the application processor be able to take care of it when it's not lifecycle manager?
- CI
- Working towards getting something that we can regression test against
- rpmsg char create / destroy channels from userspace
- Driven by Aurnaud from ST
- Aligned approach w/ Bjorn
- Some missing functionality from userspace from RPMsg character driver
- So that Arnaud can upstream his RPMSg tty driver
- Makes userspace more complete. Broadens use cases
- rpmsg tty
- Driven by Arnaud to generate remote tty device from remote processor
- Would like remote processor to create a tty that Linux can see, lightweight on RP side. No new virtio channel.
- Next meeting: Oct 22
- System DT
- Finalize: Need to solidify OpenAMP RP to generate remote processor bindings
- Finalize: Bus firewalls w/ ST - getting closer to be finished
- Introduce support for above in Lopper
- Next meeting: Oct 22
- App-services
- Goals from original meeting remain: Enable connectivity for network access, console access for higher level applications & middleware to use their expected ways to
- Enable higher level APIs for collaboration & connectivity in AMP environment when no Hypervisor w/ guests running natively. Daemon still there, based on KVMtool.
- Want to align system architecture w/ when there is a Hypervisor
- Want to use protocols that exist
- Working on network & vsoc to have socket based IPC without network stack
- Exploring alignment w/ Stratos project & System DT
- Have been using KVMtool git, but haven't pushed changes up yet
- Bill: Public repo of fork would be good 1st step
- KVMtool is a VMM, but in our case we have a remote machine instead of virtual machine. Could have adapter for KVM & for OpenAMP.
- Would like to demo at next app-services meeting
- Next meeting: Oct 27
- Bill: Is the presentation available from app-services meeting last month? Not yet
- Bill for Loic: He would like to see app-services model expanded to include some support of RPMsg. Maybe not in 1st 6 months, but hopefully in next 6 months.
- Maarten: Helpful to have access to that low-level mechanism for configuration. Could try to engage RPMessage community
- Bill: There is work underway in audio space
- Arnaud: Relationship across groups - RPMSg services, generic DT to represent remoteproc node between SystemDT & RP groups: How to have cross-functional discussions?
- Tomas: Identifying at steering committee. Could invite other working group speakers to that working group's meetings.
- Stefano: Having system DT under OpenAMP is so we can collaborate
- Maarten: Will have to align on sharing config space & sharing interrupts. Will start joining RP call.
- Maarten: Is anyone able to work on having an open source runtime like Zephyr, instead of our proprietary one? Would help to have a developer collaborator in open code base.
- Stefano: In Stratos: Use Zephyr as Dom0 on Xen, then run KVMTool there to provide virtio back-end
- Maarten: We're seeing KVMTool as a Linux tool in the system & that the remote OS be Zephyr. But a system without Linux is interesting.
- Stefano: B/c need to be privileged, want to be small, hence looking at Zephyr
- Stefano: How can virtio back-end provider run not necessarily privileged (e.g. shared memory)
- Tomas: Using Zephyr & open source components as example helps w/ CI
- Bill: Getting base CI up first, then adding more use case/test case
- Maarten to post his app-services slides
- Maarten to look into making a public repo of the app-services work so far
- OpenAMP RP
- Do those goals require any budget $? (e.g. tools licenses)
- Once CI is up, our virtual hosting costs will go up, even if not in LAVA
- Governance: Stefano to present how Xen Project makes decisions and resolves conflicts
- Stefano's slides here
- Background: This is informative, to help us see how others solve the problem.
- What is decision-making & conflict resolution?
- How to make decisions & resolve disagreements?
- How to make process clear, documented & avoid bureaucracy
- Who are the stakeholders?
- How to conclude the discussions?
- How to be transparent to community about how new big decision was made?
- Lazy consensus
- Could be useful to add for OpenAMP
- Formalizing what typically happens when ppl don't reply
- +2: Strongly in favor, +1: In favor
- 0 or no reply is neutral
- -1: Not in favor, -2: Strongly not in favor
- Lightweight
- Helps to gauge interest & resolve disagreement. Everyone is allowed to reply, but the stakeholders are the ones who are counted in the vote (leadership team + lead on topic).
- This is used when there is a proposal when a vote is needed & there is no obvious technical best choice (a few times a year)
- Xen Leadership team decisions
- Committers are the leadership team in Xen
- We probably don't need for OpenAMP b/c have TSC & TSC voting method documented
- This is rarely used (Stefano can't recall thelast time)
- Next call in December
- Tomas Evensen (Xilinx) - voting member
- Maarten Koning (Wind River) - voting member
- Vicky Janicki (Linaro) - voting member
- Ioannis Glaropoulos (Nordic) - voting member
- Etsam Anjum - voting member
- Loic Pallardy (ST) - voting member
- Poonam Aggrwal (NXP) - voting member
- Mathieu Poirier
- Nathalie Chan King Choy
- Arnaud Pouliquen
- Ed Mooring
- Stefano Stabellini
- Bruce Ashfield
- Nathalie: Welcome to NXP as a new member company
- Tomas: Update from the OpenAMP board meeting
- Bill, Maarten, Stefano: working group updates
- Bruce: Lopper update
- Remaining governance items for discussion
- When to reconvene?
- 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
- (Informal) openamp-rp call on devicetree bindings for remote procs is a different target audience than system-dt and boot-arch lists, because focusing on how to move forward while system-dt is sorted out. So, do not need to cast the net that wide for next Thursday's call.
- Nathalie: Welcome to NXP as a new member company
- Poonam will be representing
- Tomas: Update from the OpenAMP board meeting
- Working on Code of Conduct. Looking for volunteers for Code of Conduct committee.
- All: Please contact Tomas & Nathalie if you are interested in being on the Code of Conduct committee.
- Bill will continue to lead OpenAMP-rp group after he leaves TI at the end of July
- Budget: What we could use the budget on. Currently, the main cost is infrastructure for website, etc. Have been considering licensing safety checking software for CI loop.
- All: If you have ideas for licenses or other items for our small budget, let the OpenAMP Board members know.
- OpenAMP presentation by Stefano & Nathalie at ELC NA to spread the word about OpenAMP.
- 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.
- Etsam & MGC: White paper & Electronic Design News Magazine
- Electronic Design News Magazine: How you can use OpenAMP to communicate between domains in mixed criticality system. Added some extra bound checking in virtio & added prevention of interrupt __ attack. https://www.electronicdesign.com/markets/automotive/article/21135976/using-openamp-to-address-mixed-safetycritical-systems
- White paper: Etsam & Jeff authored to introduce OpenAMP. Focuses on OpenAMP library. Working on incorporating info on System DT & App Services. Then we will post on the website.
- Working on Code of Conduct. Looking for volunteers for Code of Conduct committee.
- Bill, Maarten, Stefano: working group updates
- Mathieu for openamp-rp
- Working through problems wrt introduction of new SoCs
- Rob thinks we should wait for System DT to be in place for new multicore remote processors to be added, but we can't really wait for that to happen. This will be the topic of the next call.
- Character interfaces: Goal to consolidate things, while staying flexible. Challenging b/c vendors have implemented solutions over the years - need to work together to make the designs more generic.
- Virtualization: using RPMsg for soc-soc or communication over PCI bus
- Please join the call (more context than mailing list): The more people who join the discussion, the better the solution
- Stefano for System DT
- Working on system DT binding for firewalls
- OpenAMP remoteproc binding
- Nathalie: Should we invite the system-dt & boot-arch list to openamp-rp meeting?
- Mathieu: Focus will be on how to move forward while System DT work progresses. Rob would like us to be as System DT centric as possible.
- Stefano: Don't think System DT folks want to delay remoteproc.
- Loic: 2 aspects: Generating configurations for firmware (no link w/ remoteproc), How to describe shared resources (virtio, memories) which is missing generic DT definition for that. Arnaud posted to openamp-rp list on this. Non-standard way for how shared memory is defined & how to probe virtio bus. Decoupling will require good bindings that are generic for everyone & will go in right direction for Rob. In remoteproc working group need to work on standardization for vdev, RPMsg devices.
- Mathieu: Need to also discuss that w/ Rob.
- Loic: Maybe can review Arnaud's proposal. Will need to re-work patch proposal to make clearer. We have some DT examples that can share. Want to make sure bindings in good shape
- Mathieu: No need to cast wider net
- Loic: Agree
- Maarten: App services
- Last summer demo on proxy running on Linux w/ RPMsg & services running on top to enable console, socket, file system. Intent was to open source the proxy & have drivers tied to RPMsg. It turns out, those drivers already exist. If we support those drivers, then would be enabling app services in OpenAMP environment without virtualization with virtio drivers. Putting some ifdefs in kvmtool to use the proxy part for remote OS w/ console, filesystem & vsoc domain unified between the 2 instances. Networking would be a possibility. Remote debug could be enabled. This saves us from writing new drivers for the remote OS. Aug 18 meeting
- Loic: Could we move to early Sept? Know Loic & Arnaud will be OOO all of Aug.
- Nathalie: Send a question to list about rescheduling to September
- Mathieu for openamp-rp
- Remaining governance items for discussion
- Code of conduct
- Consensus & Conflict resolution
- Stefano: This is where Governance gets used most, in Stefano's experience. Conflict/disagreement occasionally will arise. It helps to have explicitly written down system to solve the conflict. In Linux case w/ benevolent dictator, they would decide. In other types of community, need to figure out how to decide, e.g. if maintainers don't agree.
- Tomas: Any good examples we could use?
- Stefano: Xen suggests to try to resolve without vote. If can't then vote among committers. Way to express preference level (+1, +2, -1, -2). Try to avoid -2 for everyone.
- Tomas: What if even # of maintainers?
- Stefano: Deciding vote becomes the TSC.
- Tomas: Anyone else have suggestions for templates we could take a look at?
- Stefano: We could just say TSC decides, since OpenAMP has a nicely defined TSC.
- Stefano to send out example of Xen consensus & conflict resolution process
- Coding style guidelines: Checkpatch: Comes from Zephyr
- New features: also discuss in working group calls
- Testing:
- Arnaud let us know what is current requirement for testing.
- Tomas: Do we have info on how ppl can contribute to CI loop or testing?
- Ed: Not yet. It's still active development.
- Documentation:
- How to move forward on decision wrt Sphinx
- Stefano: Think it is the right way to go, but it will take some effort to set up. Converts .rst markdown and creates HTML. It's the most widespread tool in open source projects.
- Ed: Documentation is on radar, but not active yet.
- Lopper update:
- Tomas: It's available on devicetree-org GitHub. Being used by quite a few people. One use is taking System DT & splitting up into traditional DT. Bruce is adding features: YAML reader/writer, firewalls
- When to reconvene?
- Tomas: We have an OpenAMP Project update talk at Linaro Virtual Connect
- Mathieu has a Linaro Virtual Connect talk about remoteproc & RPMsg in last year, current challenges & where we want to go
- Nathalie: Shoot for 2nd week of September for TSC to schedule next call
- Tomas Evensen (Xilinx) - voting member
- Bill Mills (TI) - voting member
- Grant Likely (Arm) - voting member
- Ioannis Glaropoulos (Nordic) - voting member
- Loic Pallardy (ST) - voting member
- Jeff Hancock (MGC) - voting member
- Clement Leger (Kalray) - voting member
- Vicky Janicki (Linaro) - voting member
- Mathieu Poirier (Linaro)
- Ed Mooring (Xilinx)
- Bruce Ashfield (Xilinx)
- Stefano Stabellini (Xilinx)
- Nathalie Chan King Choy (Xilinx)
- 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
- 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-Tree-sub-group
- 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
- 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
- Bill: API stability.
- Shortly after last call, sent out an email. (subject "[OA-Tsc] API and Wire protocol stability")
- Looking at Zephyr API Lifecycle https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html
- We don't need all the states before stable
- Zephyr only puts in deprecated state for 2 releases. If you're only occasionally sync-ing up, the API you're using is not guaranteed to be there. Think OpenAMP should take a longer approach.
- Arnaud had suggested during openamp-rp call: They'd like to take even more aggressive stance & you only break the API when absolutely necessary & discuss each breakage.
- Tomas: Different between machine local API & protocol between 2 machines. Between machines should have long cycle & try to be backwards compatible. If it's local & could re-compile, could have different.
- Bill: We shouldn't break wire stability once the 2 projects are in sync upstream. Should try to make older firmware compatible. Functionality can evolve w/ different mechanisms. But, any break of wire protocol needs to be reviewed by TSC.
- Bill: What lets you evolve more rapidly is to have LTS, but think our project is too small to have resources to support LTS. Better to have stronger API compatibility statement.
- Tomas: Agree
- Bill: We don't have a lot of control over what will change in kernel, just can voice opinion. Scope of stability is in the projects we're adding that are independent of the kernel.
- Tomas: Think you captured it well.
- Vicky: equivalent of 2 years (time or releases) or allow it to slide w/ min/max. Does one make it easier/harder than the other?
- Bill: 2 years is easy policy to understand, but the range is if it's simple to keep it compatible then can stay longer, or if big problem to keep old way then can pick the shorter window.
- Nathalie: Does time work for the seldom updaters?
- Bill: If care about all the features, they will update often, but for some we are means to an end & they will want transparency.
- Tomas: Like the idea of minimum time, but then up to maintainers if want to keep for longer period.
- Stefano: Can ask for volunteer of maintainership for something that will disappear & if none, then remove it.
- Bill: What timeframe to close the discussion?
- Grant & Ioannis: Let's continue discussion by email
- Tomas: Make decision at next TSC call
- Tomas: Recap decisions from Board call:
- TSC chair term is 1 year
- TSC decides on changes of leadership in the sub-groups.
- Tomas: Motion: Stefano to take over leading System DT
- Vicky: second
- No objections
- Decision: Stefano is new leader of System DT sub-group
- Stefano: System DT goals for next 6 months
- Spec: Go into more detail & be more formal for domain configuration (nodes & new bindings that were under chosen & now under domains). We added clear examples & wording, but would like to get it more precise.
- Firewalls: We've been working recently on trying to formalize bus firewall configurations in System DT. We have an initial proposal that will be presented tomorrow. Will try to get that in.
- Lopper: Bruce: Just pushed Beta version on devicetree-org & will make it public in a few hours to get issues & pull requests. Aiming for more generalization & working with libraries. Easier OOB. There is a To-do file. Got lots of good feedback from Kalray.
- Clement: Thanks for Lopper. We are just using for subset of DT & seems to work well.
- Stefano & Bruce to write up the goals in the OpenAMP Wiki. Nathalie will send link.
- OpenAMP remoteproc
- Kernel side: we're trying to play catch-up with what everyone is holding. Until that is behind us, won't be too prescriptive about what we're trying to do.
- Ed & Arnaud have some pull-requests to look at in next 6 months.
- 12-months: Gaps to fill in once we collect all the use cases from what people need to upstream
- GitHub issues & pull requests
- Grant: Think PRs should be fine
- Bill: This doc was written a while ago & not up to date. Working model is PRs & not what the doc says. People seem to assume that we're using issues. Wendy had been using GitHub issues.
- No one expressed objections
- Ed: Update the governance document to reflect what we're actually doing
- Grant: This process is very developer-centric. Should everything be covered at TSC? We have very experienced engineers with how to do this stuff - are we trying to formalize or address a problem?
- Bill: Think we're just trying to rubberstamp what maintainers are recommending b/c want all the sub-projects to use the same approach.
- Stefano: This is a list of things that, at some point, someone needs to decide to have a working Open Source project. TSC doesn’t have to decide all of them.
- OpenAMP releases
- Vicky: We just had a release: What does that mean?
- Ed: openamp & libmetal
- Tomas: Eventually, will have higher level services - should they have same cadence?
- Bill: At least want to make sure there is a cohesive set that people can use at a given time
- Tomas: Let's continue with 2x/year until there is a need to change.
- Vicky: Makes sense
- Documentation
- Bill: A lot of projects use Sphinx & Read the docs
- Vicky: Let’s try to be consistent & set expectations. Will be important when for being certification-ready.
- Nathalie: A lot on OpenAMP wiki right now
- Bill: That's more project management/status, rather than "formal" docs
- Ed: Release notes went into the GitHub release.
- Ed: Had an assignment from Manju to look at OpenAMP docs to do a gap analysis. Not sure what the priority is on that.
- Tomas: Can you also look into where it should go when you do that?
- Ed: Makes sense. Would like assistance from someone who's up to the state of the art in the field.
- Bill: Zephyr uses Sphinx and ends up with Read the docs
- Grant: Linux kernel uses Sphinx
- Stefano: Xen uses Sphinx
- Clement: Kalray using Sphinx
- Vicky: I think we can take that as a recommendation. People will be familiar with use & setup.
- Ed to do gap analysis of OpenAMP documentation & look at using Sphinx
- Stefano: Sphinx is tool that lets you turn Markdown into HTML or PDF. Read the docs is an online CI loop for docs, which uses Sphinx to put it on website.
- Next call: 2 months
- Tomas Evensen (Xilinx) - voting member
- Bill Mills (TI) - voting member
- Maarten Koning (WindRiver) - voting member
- Ioannis Glaropoulos (Nordic) - voting member
- Loic Pallardy (ST) - voting member
- Etsam Anjum (MGC) - voting member
- Clement Leger (Kalray) - voting member
- Vicky Janicki (Linaro) - voting member
- Mathieu Poirier (Linaro)
- Ed Mooring (Xilinx)
- Bruce Ashfield (Xilinx)
- Stefano Stabellini (Xilinx)
- Nathalie Chan King Choy (Xilinx)
- 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
- Interface compatibility
- MISRA & Functional Safety
- (ran out of time here)
- update of the OpenAMP GitHub members: https://github.com/orgs/OpenAMP/people
- To define criteria to be member and who takes the decision of adding/suppress members
- List of the new candidates (I would suggest to add TSC members)
- Pick additional topics from Ed’s Governance list. Options are:
- Selection of new features for development
- Testing
- Documentation
- Branching & tagging strategy
- Release process
- 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.
- Tomas Evensen officially voted in as TSC chair
- Officially vote in a TSC chair
- Only 1 nominee: Tomas. Tomas officially voted in as TSC chair.
- We should pick an interval for TSC chair election:
- 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.
- How do we change working group lead?
- Make it official at Board meeting that working group proposes someone & TSC approves. Working group lead should attend TSC calls.
- App-services update & looking for interest in porting PoC to Zephyr
- Looking at the problem top-down. Need to have compatibility & meet expectations, instead of going for most optimal interface.
- Heterogeneous & homogeneous compute
- What are the application requirements for connectivity?
- Being able to deploy natively
- Standard APIs
- Resource sharing w/ Linux
- Looking at leveraging a log
- Down to other hypervisor
- Across to other runtimes over OpenAMP
- Across other CPU clusters over shared memory
- Sample implementation: VxWorks & WR Linux (Yocto based)
- Tomas: Would be good to have sample w/ Zephyr, Yocto based to align w/ Open Source runtimes
- Looking for a dev who can code w/ us
- Might be a nice sprint once the travel restrictions are over. (virtual sprint?)
- Loic: To consider for roadmap: OpenAMP is compatible w/ Zephyr & standalone. If we want it to be easy to integrate w/ different platforms, do we need porting layer for the different RTOS? They have networking stack, USB stack, but no inter-processor communication stack.
- Maarten: Having a portable implementation that can move to the different runtimes is interesting. Like the idea. The top down layer that we put on top more portable.
- Briefly: Start thinking about goals for next 6 months
- Tomas & Stefano to discuss for System DT: Lopper, Firewalls
- Bill: OpenAMP-rp:
- #1 aspiration is to reduce the technical debt that everyone is carrying in next 6 months. Maybe 1 year.
- Tomas: CI is getting there. Can we document the goals/aspirations to help those outside the working group & attract more members?
- Nathalie: Can document in the Future and Current work pages in OpenAMP Wiki
- 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
- Interface compatibility
- Bill: API stability policy is what I looked into. Not about making API the same in different __. That would be a different topic.
- I've looked at different policies
- Zephyr community has done pretty good job to define a policy for API stability. Suggest we adopt that as a starting point.
- Probably good reason to make some changes. OpenAMP is a smaller set of things than Zephyr, so don't need as many levels as Zephyr. Can simplify the model.
- Once an API is deprecated, it has to be supported for 2 releases (= 1 year), but most ppl don't pick up every 6 months. We should consider what our deprecation period would be.
- Bill M to write up the thoughts on API stability policy & point to the Zephyr policy
- Tomas: Agree we should have a policy
- Backwards compatibility
- Version #s
- Feature bits
- Bill: Policy on wire protocol stability is another topic. We need to take a harder line on that - 1 year deprecation period is not enough.
- Bill M volunteers to drive the topic of wire protocol stability.
- Bill M suggests it's a TSC topic, rather than just openamp-rp topic
- Etsam: If we have different rpmsg APIs for different implementations, will affect app-services team. e.g. if they use OpenAMP API signature & that doesn't stay for other implementations, won't be able to seamlessly use w/ other implementation. Will probably need some porting layer there. Won't be trivial to use same API signature on all implementations - but can be a stretch goal & use Linux as reference.
- Bill: Not volunteering for this topic. Right road is via different implementations & seeing what issues come up. Single API could lead to inefficient implementations. Higher-level API is better target for commonality than the implementation-level API.
- Etsam: At least if the signature can be same. Don't have to be same implementation.
- Tomas: One way to look at is top-down, via app-services. If we don't have consistent APIs underneath, then there will be an abstraction layer so you can port to multiple things & maybe that can guide us towards a common API we can push.
- Etsam: App-services can give the guidance. Should consider in the design.
- Bill: API stability policy is what I looked into. Not about making API the same in different __. That would be a different topic.
- MISRA & Functional Safety
- Tomas:
- Even if we don't go for safety certification, we should make it easier. We should come up w/ statement around this - are we going to pursue it? Checking tools cost $$, so it's hard to put them in the CI loop.
- Vicky: Zephyr is looking into it
- Updated coding guidelines presented to Zephyr TSC in 1st round. Got lots of feedback. A subset was selected. 4 remaining items need agreement on.
- Doesn't make sense to be 100% MISRA C compliant. You have to figure out what makes sense in your environment & then you have to document why you will omit certain ones. Advisory vs Mandatory items.
- Zephyr trying to see if they can get the tools sponsored for the project. One of the tools offers free if you sponsor it from Marketing standpoint.
- Stefano: Xen
- MISRA C spec is not openly available. Not super expensive (~100 GBP). But not all the maintainers had access to the spec. So, we had to get some Xen project budget to get 1 MISRA C license for each of the maintainers. We might have to be prepared to pay for a license for a major contributor, so that they can read the spec & fix their code.
- Tooling to check MISRA C: We have a free-for-Xen-project-only license that was provided to us by Perforce. Did analysis
- Having tool available but not in CI loop is limited usefulness, so you know if things improve or get worse when a patch comes in. Hard to know by code inspection alone.
- That tool is not easy to integrate in CI loop b/c it's web-based & not meant for script integration.
- Easy to have a lot (>50%) of false positives, e.g. only check C code, not assembly (e.g. all the bit setting/clearing calls)
- Resiltech is sponsoring analysis for us
- To reduce false positives
- To integrate into CI loop
- Using Scitools Understand, and buildspy plug-in
- Buildspy helps to reduce false positives: Managed to reduce the ones from assembly
- Need to document the exceptions & maintain
- It's difficult to understand how an exception can be written. Kind of like what lawyers do for regulations. Engineer may find hard to use the correct wording.
- Need an expert in certification who is consulting for the project who can tell us what exceptions are acceptable or not
- Etsam: Is there any requirement from any functional safety standard for which MISRA C rules are supported?
- Stefano: Yes there are. Some items are Mandatory & others Advisory. As you go up through ASIL (D strictest), more rules are expected to be followed.
- Tomas: What is Xen, Zephyr strategy to pursue ASIL level?
- Stefano: Xen initial drive was for automotive. They cared about ASIL-B.
- Vicky: Believe Zephyr pursuing 61508… it's the 1st level. We aren't pursuing automotive requirements, which are much stricter. Also, must determine what is the core set of components (kernel + what else) and not try to certify the whole code base.
- Etsam: OpenAMP has open-amp and lib-metal. Will have to consider components separately.
- Tomas: We should come up with strategy for where we position OpenAMP. Options for level:
- Do nothing
- Check in CI loop & try to clean up the code to a certain level & Document
- Get through a certification (probably more than what we want to do)
- Tomas: How important is this to the group?
- Vicky: You will get more interest if you are ready to be certified. Have some docs & meeting some standards. It's definitely a value-add + gets wrapped into Zephyr.
- Sounds like important to MGC
- Xilinx: Important, we are going in this direction
- TI: Ready for certifiable is the new target for most low level SW
- Kalray: We are looking for certification but not sure what parts of our code need to be. Don’t know if we will need OpenAMP to be.
- ST: Depends on context where we want to use our product. Ready to certify is added value for code quality.
- Nordic: <audio></audio>
- WR: There is overhead to this work. But it's hard to retrofit, so having some diligence in our conventions is good, as long as not too onerous. i.e. don't go for highest level b/c would slow the project down too much.
- Vicky: It's a long process to get going. We can lay out the first few steps we want to take, while we watch what Zephyr & Xen do.
- Tighten coding guidelines?
- Which target areas for readiness?
- Tomas: Can we try to get package deal on tools w/ Zephyr or Xen if they get into negotiations?
- Tomas:
- Bill Mills (TI) - voting member
- Maarten Koning (WindRiver) - voting member
- Ioannis Glaropoulos (Nordic) - voting member
- Etsam Anjum (MGC) - voting member
- Tomas Evensen (Xilinx) - voting member
- Grant Likely (Arm) - voting member
- Ed Mooring (Xilinx)
- Bruce Ashfield (Xilinx)
- Nathalie Chan King Choy (Xilinx)
- Officially voting in a TSC chair
- Deciding which BUD20 F2F OpenAMP meetings need to be scheduled at a PST-friendly time for call-ins (these will be the last of the day in Budapest)
- TSC discussion topics for F2F at BUD20 so ppl can decide about travel
- Should it be TSC or individual work groups who decide & if TSC:
- Should we use GitHub issues for tracking bugs & upcoming work?
- Should we use GitHub Pull Requests or mailing list submissions for code contributions?
- Vote on if we should adopt the Zephyr guidelines for OpenAMP code
- Remaining time: Continue to go through Ed’s list of governance items that need discussion
- Nathalie: Send out email to ask for TSC chair nominees
- Ed: Update push access to libmetal & libopenamp to just Ed & Arnaud
- Ed: Investigate OpenAMP GitHub ownership
- Nathalie: Ask Bill Fletcher about moving over GitHub repo for website to OpenAMP GitHub instead of OpenAMP Project
- Nathalie: Put MISRA & functional safety on agenda for next TSC call
- Bill Mills: write a couple paragraphs on what the policy should be around interface compatibility & send out for review to list
- Nathalie: schedule next TSC call over email
- Nathalie: Check ahead for quorum for next call
- All: Send suggestions for next TSC call agenda
- Ed & Arnaud (open-amp & libmetal maintainers) will be the only ones with commit rights to those GitHub repos. Will continue to use GitHub PR flow for contributions. Ed & Arnaud should also submit PRs for what they commit.
- OpenAMP will adopt the Zephyr coding style guidelines
- 6 voting members -> Quorum
- Ed: Arnaud reported he thinks no one from ST will be able to join
- Nathalie: Vicky answered as Tentative
- How to select a TSC chair?
- Tomas OK to continue in acting, but happy if someone else wants to nominate others
- Do we have any candidates?
- Maarten nominates Tomas & multiple seconds
- Ioannis: In Zephyr there is some time over email for people to nominate & elect
- Tomas proposes we send out email to ask for candidates & either we vote over email or next meeting
- Nathalie: Send out email to ask for TSC chair nominees
- Linaro Connect cancelled. When to plan F2F?
- Bill: Maybe backup plan could be to do something around ELC
- Tomas: That opens up March week for possible System DT sprint
- Budapest?
- Cambridge?
- Grant: Hard to have a hacking sprint with another event b/c reduces available time
- Tomas: Could have other F2Fs (e.g. TSC F2F) co-located with another event since not as much time required
- Should we use GitHub issues for tracking bugs & upcoming work? Should we use GitHub Pull Requests or mailing list submissions for code contributions?
- Ed:
- co-maintainer (Arnaud) is not here
- Manju was strongly in favor of email, but is no longer involved in OpenAMP
- Would like to pick something & be consistent
- We've been continuing to use GitHub PR
- Tomas: Should it be TSC or individual work groups who decide?
- Bill:
- Would be good to have it uniform across the different libraries under the same umbrella (kernel still goes by its own rules)
- PR model is OK. Even kernel is talking about a more managed methodology, which isn't developed yet. Could consider using that if/when that is available.
- Tomas: Should we just continue with GitHub PR then, since Manju not involved?
- Ed: 8 ppl have push access to Github repositories for libopenamp & libmetal
- Arvind, Cyril, Etsam, Wendy, Kumar, Arnaud, Felix R., Ed
- So, who has access? It's not just Ed & Arnaud.
- Bill: Should just be via maintainers, who also should do PRs
- Bill: Move to change to have just maintainers having push access & they should use PRs
- Tomas: Makes sense. Do you think Arnaud will object?
- Ed: Not likely b/c seems sensible. Arnaud will be OOO for a week though, starting today.
- Tomas:
- When we had discussion about maintainers, it was implied that just they would be maintaining & should formalize.
- Does anyone object to deciding now? Can change later if necessary.
-
Bill: Motion: Ed & Arnaud are maintainers of libmetal & libopenamp. For those 2 repos, they should be the only ones who can commit. Discipline should be that the maintainers also use PR.
- Tomas: Seconded
- No objections
- Ed: Update push access to libmetal & libopenamp to just Ed & Arnaud
- Bill: Not sure about the other repos besides these 2 & meta-openamp
- Tomas: System DT is separate
- Bill: We have OpenAMPProject (just website) and OpenAMP in GitHub
- Nathalie: OpenAMPProject created by Kyle for website, so probably should just move to OpenAMP, where everyone else expects OpenAMP stuff. I get impression Linaro IT is OK with us managing it, since I am able to force merge my PR for website & haven't seen any review of my recent PRs.
- Bill: Who "owns" OpenAMP GitHub? OpenAMP Community Project? Xilinx? Is there a notion of ownership?
- Ed: Investigate OpenAMP GitHub ownership
- Tomas: If it's owned by Xilinx, makes sense to move ownership over to community project
- Bill: What about website?
- Nathalie: Ask Bill Fletcher about moving over GitHub repo for website to OpenAMP GitHub instead of OpenAMP Project
- Ed:
- Vote on if we should adopt the Zephyr guidelines for OpenAMP code
- Bill: How much work would it be to conform?
- Nathalie: Believe Arnaud reported last call that he ran checkpatch & thought it's not far off
- Ioannis: checkpatch CI?
- Ed: He corrected 21 violations
- Ioannis: Would expect 100s, which should still be OK
- <nathalie></nathalie>
- Ioannis: Is the result logged somewhere?
- Bill: Zephyr only has 1 circumstance to use spaces, otherwise tabs
- Ioannis: Checkpatch enforces. Use tabs.
- Ed: Arnaud's PR for correcting the violations hasn't been merged yet
- Tomas: There was coding style & we decided to separate out MISRA
- Ioannis:
- Yes, should separate those discussions.
- What's plan to enforce the guidelines? Run checkpatch in CI?
- Ed:
- Would like to have checkpatch integrated into GitHub flow
- Having PR rejected might be overkill
- Ioannis:
- For new contributors, better if they just get red mark asking to fix, instead of being stopped altogether
- Ed:
- CI not 100% yet for GitHub - OpenAMP long build time
- Have OpenAMP being tested in LAVA. Could put checkpatch in this flow.
- Tomas: Etsam, you guys were pushing for a common coding style. Zephyr OK with you?
- Etsam: OK w/ Zephyr coding standard
- Tomas: Had discussed before & announced plan to vote this week & have quorum, so let's proceed
-
Tomas: Motion to use Zephyr coding standard per Zephyr project.org documentation
- Maarten: Seconded
- No objections
- MISRA & functional safety
- Tomas: Are we ready to have that discussion? Prefer to have Stefano present b/c he's been looking into that on Xilinx team
- Bill: Think it's a need for the code base
- Nathalie: Put this on agenda for next TSC call
- Looking at Ed's list
- API Compatibility policy
- Ed: When we change the interface, how long must we keep backward compatibility? Do we give new interface with new name & keep old interface?
- Tomas: Good to define the process & not based on what maintainer decides for a given change
- Ed: Was not well addressed before this
- Tomas: Beyond APIs, e.g. virtio protocol
- Ed: Yes
- Etsam: We have 2 kinds of API in OpenAMP code base for remoteproc & for rpmessage communication
- Rpmessage APIs: Should conform to what is in Linux upstream
- Remoteproc: Specific to what was designed in OpenAMP code base
- Are you asking about moving from 1 version of OpenAMP to the other, or where driving the standard from?
- Ed: Also libmetal
- Etsam: libmetal-openamp interface should stay same when migrating from 1 version to another
- Tomas: We don't have consistent interfaces to userspace, RTOS & Linux kernel
- Ed: There are things where we present an interface, there are proposals to change bits. What is policy for how we do that? There are outstanding PRs that just change interface of a function w/ an existing name. Have gut feeling, but want to spell out formally.
- Tomas: Should have a process, e.g. change name & keep old & deprecate for a while
- Etsam: If open-amp & libmetal APIs, should have this discussion in openamp-rp subgroup call. Agree need some criteria. Need to know what is guiding principle to create API & maintain it.
- Tomas: TSC can decide that the relevant working group has to make a decision & not just maintainer.
- Bill: Agree TSC should define a policy & can discuss how to handle in openamp-rp
- Etsam: Agree
- Bill: Even greater need to maintain compatibility @ protocol level. Where possible, should maintain backward compatibility.
- Tomas: Should call it interface compatibility
- Bill: Expect protocol compatibility to be more stringent & longer lasting
- Etsam: Agree & another dimension. Rpmessage API try to support what's in Linux upstream. So have to depend on Linux side.
- Bill: It's a topic for discussion in rp call if that is an important goal for libmetal & openamp library. It was a good starting point to not invent something new. It's not a high value goal to keep to kernel way b/c we are doing something different
- Tomas: Who wants to write a couple paragraphs on what the policy should be, for everyone to review?
- Bill: Volunteering. Does anyone know a good reference that we could pull from? Will check Zephyr.
- Bill: write a couple paragraphs on what the policy should be around interface compatibility & send out for review to list
- API Compatibility policy
- When to have next TSC meeting? About 1 month from now.
- Nathalie: schedule next TSC call over email
- Nathalie: Check ahead for quorum for next call
- All: Send suggestions for next TSC call agenda
- Voting members of TSC: quorum reached
- Vicky for Linaro
- Dan Milea for Wind River
- Tomas for Xilinx
- Bill Mills for TI
- Etsam for MGC
- Clement for Kalray
- Ioannis for Nordic Semi
- Loic for ST
- Mathieu (Linaro), Tony (Xilinx), Nathalie (Xilinx), Arnaud (ST), Bruce (Xilinx), Mark Grosen (TI), Ed (Xilinx), Stefano (Xilinx)
- Non-Linaro members: Contact Nathalie, Tomas, or Vicky if you are not a Linaro member and need the OpenAMP discount code to attend Linaro Connect BUD20
- All: Review the Zephyr guidelines, for discussion next TSC call if we should adopt these for OpenAMP
- Ed: Check with Wendy if Xilinx had put OpenAMP through MISRA C checking in the past
- Re-cap decisions from last Board meeting & TSC meeting for the wider audience
- Who can be part of TSC? 1 vote per OpenAMP board member company. Participation is open.
- How to select maintainers? TSC votes on maintainers of the repositories that OpenAMP owns. TSC should to pay attention to the contributions that the person has made to the project
- Who are maintainers? Libopenamp & libmetal have Ed & Arnaud as co-maintainers
- Uniform coding standard for all OpenAMP code. Can discuss for new code bases coming in full cloth
- Who is attending Linaro Connect BUD20?
- TI will be there w/ a few ppl
- ST - Loic should be there
- WR - Maarten & maybe Dan M.
- Kalray - Not attending
- Mentor - Will check w/ Dan D. & Arvind
- Linaro - will be there
- Arm - TSC figures Grant will be there
- Nordic - Maybe
- Xilinx - will be there
- Contact Nathalie, Tomas, or Vicky if you are not a Linaro member and need the OpenAMP discount code to attend Linaro Connect BUD20
- What meetings to have at BUD20?
- Working groups
- System DT
- Openamp-rp
- Dan: Check if Maarten planning a higher-level services meeting
- TSC
- Let's discuss in upcoming Board meeting if Board needs to meet f2f
- Wed will be very few sessions, so is the discussion/hacking day
- Will plan the times once we know more of the schedule
- Working groups
- Governance topics: (it’s a long list, we’ll start chipping away at it in this call)
- Coding standards/style
- Considering Zephyr:
- https://docs.zephyrproject.org/latest/contribute/index.html
- https://docs.zephyrproject.org/latest/contribute/index.html#coding-style
- Mathieu:
- What's the biggest open source environment that we get into?
- We should just have 1 coding guideline for OpenAMP
- Bill:
- Agree we can only have 1. Disagree that it must be an open source one. We should pick the best to hit a wide range of targets.
- Zephyr is a small percentage of our use cases today.
- Etsam:
- Think biggest use is Linux user space.
- Think Zephyr makes a lot of sense. It's pretty much Linux, with some improvements. A lot of others are also similar to Linux. Think adopting Zephyr will minimize refactoring.
- Stefano:
- Have seen that it helps to take an existing one from open source b/c then can re-use the tools for checking, transforming.
- Another we can consider is BSD.
- Tomas:
- Zephyr following Linux style mostly w/ 4 things changed.
- Arnaud:
- During OpenAMP restructuring we went with Zephyr & ran the Zephyr checkpatch last week & we are still pretty close.
- Bill:
- Zephyr did go through a similar process we are going through now.
- Hopefully they looked at the cases that came up in safety certification, MISRA. Think some of the other coding guidelines haven't considered these.
- Etsam:
- Decoupling the style vs. standard which needs static analysis tool
- We internally had run the static analysis & there are a lot of deviations from MISRA C.
- Vicky:
- Zephyr TSC is discussing recommended guidelines. We have spreadsheet of guidelines & need to decide which to follow. Then have to write docs to explain why some of the items aren't being followed. Some are "must" vs "nice".
- Effort will be substantial to meet guidelines for safety & security, but if you're going to do it it's better to do it earlier.
- Etsam:
- Linux doesn't restrict goto, but MISRA discourages. Also, think about reason: Is it for some safety requirements, or for a certification
- Tomas:
- Functional safety is not going away.
- OpenAMP is library being used in all sorts of environments, so should do what we can to make it safety certifiable by others. However, we don't want to be the 1st open source project to do it.
- Zephyr, Xen are working on it. Rather be following them.
- Stefano:
- Good principle, but need someone to review the code who knows MISRA well to catch violations. Static analysis tool will help a lot.
- Problems:
- MISRA C spec is not open to public, so hard to discuss rule violation
- Xen purchased the MISRA C licenses for the maintainers
- Contributor needs to be explained the violation & maybe doesn't have the license
- There are many rules & maintainer might miss in review
- Having static analysis tool in CI loop on staging tree would be helpful before push to master
- Integrating static analysis tools with CI loop isn't easy. Many tools are web based. Still trying to find one that would work for a container-based & QEMU-based CI loop.
- Most of the MISRA C rules mean well. Usually have a description why. But, when you translate into the actual implementation, sometimes it makes things worse. e.g. switch statement: GCC can detect errors & missing labels normally, but not if you do it the MISRA C way.
- Having exceptions is very complex - almost like being a lawyer
- Etsam: Most important decision is exceptions we want to implement
- e.g. OpenAMP analyzed. There was an exception 600 places in the code. Didn't make sense to change all these, so exception made sense.
- Can make OpenAMP cert-ready after some tweaks, but not make it certified
- OpenAMP is for many systems (Safety & non-safety) - need thorough bound checking between safe & non-safe side. e.g. can't bring down safe side b/c of accessing invalid memory. That's runtime & needs to be considered.
- Tomas:
- Goal is not to certify OpenAMP right now, but to make it as easy as possible for others who want to certify it, to get there.
- Might need to integrate proprietary checkers into the CI loop, so org will have to look at if we need to invest there
- Bill:
- We have to draw the line somewhere. At least, our code base is not that big. The power of having a group like this is that we're working together & can decide to make a change.
- Tomas:
- Coding style: Zephyr seems to be the leading candidate. Let's give everyone a chance to read up on it. Then we can decide next meeting.
- MISRA & other standards: Agree it's easier to get compliant sooner than later.
- Etsam said Mentor has done some analysis on OpenAMP, Ed or Stefano - has Xilinx?
- Ed: Believe Xilinx's MISRA efforts have not reached OpenAMP
- Ed: Ask Wendy if it had been attempted
- Tomas:
- Can we find some low hanging fruit & tackle specific rules that are easy to implement early on?
- Ed:
- How can you have an open source project with proprietary checking tools?
- Stefano:
- Xen: What's important is that the results are public. Also, discussed submitting special branches for checking fixes to compliance issue for evaluation.
- Considering Zephyr:
- Coding style proposal is Zephyr & will vote next time
- MISRA: Anyone who's interested can do an analysis & see if there's low hanging fruit. We'll see what Zephyr & Xen do.
- Next call: In ~4 weeks
- Coding standards/style