OpenAMP Application Services Subgroup Meeting Notes 2019 - OpenAMP/open-amp GitHub Wiki
This sub-group covers the application space that sits on top of OpenAMP. The proposed meeting cadence is roughly monthly.
Arnaud Pouliquen (ST), Bruce Ashfield (Xilinx), Dan Milea (WR), Ed Mooring (Xilinx), Grant Likely (Arm), Ioannis Glaropoulos, Loic Pallardy (ST), Maarten Koning (WR), Mathieu Poirier (Linaro), Nathalie Chan King Choy (Xilinx), Stefano Stabellini (Xilinx), Sebastien Le Duc, Wes Skeffington (Xilinx)
Maarten presented (Wind River) Isled - linux daemon which provides access to Linux resources for Safety / RT OSs with a plan of open-sourcing it and making it a platform for application services
Context:
- multi-OS architectures are becoming the norm, with the safety / RT OS sharing resources from trhe rich OS, which is almost always Linux
- code which runs on RT / Safety OSs has special constraints, and if Linux can do a job it will do the job
- non-critical and non-RT services and drivers can be provided by Linux (e.g. internet connectivity, non-critical file systems).
- Linux program which waits for a client runtime to connect to it
- RPC framework built on top of pluggable transports (sockets, shared memory - RPMsg, etc)
- provides support for: client console, port forwarding, file I/O with acces to the whole file tree, including pseudo filesystems
- includes optional RPC which can be initiated on Linux
- each client runtime has its own Linux isled daemon
- open-source isled and use it as infrastructure on which application services would build upon
- Mathieu P.: How much Linux kernel code has been modified for Isled?
- Maarten K.: None. Isled is a userspace application
- Stefano S. had a question about data passing in isled transports
- Dan M.: memcpy for now, looking into using the large buffer RPMsg payloads
- Arnaud P.: What about systems where RPMsg and VIRTIO devices are defined in the kernel, not in userspace (i.e. systems w/o any dependencies on the userspace OpenAMP library)
- Maarten K.: This is a transport-specific implementation issue and should be an isled plugin. In theory it should be doable, not investigated so far.
- Q: What isled client runtimes are people interested in? Bare-metal vs Zephyr vs FreeRTOS?
- A: Zephyr would be a good starting point, since OpenAMP is already included. FreeRTOS next.
- Stefano S.: What is the performance of isled in high bandwidth communication?
- A: Not really measured so far.
- Stefano S.: How is the safety OS handling isled failures and are there any libraries which handle this?
- A: No special libraries. Also, Safety OSs should not rely on isled or data from the rich OS sharing its resources (e.g. Linux)
Mathieu Poirier (Linaro), Maarten (Wind River), Bill Mills (TI), Mark Grosen (TI), Dan Milea (Wind River), Nathalie Chan King Choy (Xilinx), Tomas Evensen (Xilinx), Grant Likely (Arm), Arnaud Pouliquen (ST), Bruce Ashfield (Xilinx), Clement Leger (Kalray), Etsam Anjum (MGC), Ed Mooring (Xilinx), Loic Pallardy (ST), Manjukumar Harthikote Matha (Xilinx)
The purpose of this meeting is to describe some potential areas to pursue, to identify interested parties and to gather high-level input. Since this is a one hour meeting, we won’t be able to go into deep technical detail on identified topics and we won’t be making any binding decisions. Thus, it won’t be a PowerPoint-fest – it will be more of an open discussion. Brainstorm on potential topics and discuss value and priority. To prime the pump on the sorts of topics we will discuss, here are a few we have identified already:
- file sharing
- proxy and/or forwarding of IP ports
- debug proxy
- high level IPC APIs for send-receive-reply / byte streams / message-based connections / pub/sub
- IPC server registration and client binding
- application partitioning using RPCs, C & non-C languages, canonical format
- bare metal APIs (using RPC) for stdio, socket IO, other APIs
- All interested: Subscribe yourself to the app-services mailing list if you're interested in this topic (https://lists.openampproject.org/mailman/listinfo/app-services)
- Maarten: Send out the slides
- Maarten: Schedule next call for 1 month later, same timeslot, if it looks like there's enough activity to warrant a call.
- Loic: (give a little time for ppl to subscribe to the mailing list) Send pointer to example: small driver on top of rpmsg & very small piece of code.
- Bill & Etsam: (give a little time for ppl to subscribe to the mailing list) Continue discussion on list: virtio-net & socket layer
- Maarten
- Application space to sit on top of Open AMP
- What are our priorities?
- Do want to leverage past ideas
- Maarten showed 1st slide:
- 2 types of devs: Platform & Application
- App devs have different issues from Platform devs & have their own expected paradigms
- Having API to work in "expected" way for application devs
- Want to use middleware & OS services of 1 runtime from another
- Does anyone want to weigh in on the list?
- Tomas: How to add your own service or proxy from another, if you have your own thing
- Maarten: How to extend things on top, without working things underneath. Dynamically bring up servers & clients use services on top w/o having to reboot.
- Bill:
- Think this is a good list
- We use your platform dev issues for OpenCL, OpenVX. App dev just wants to use OpenCL, OpenVX. Do you consider that existing messaging paradigm that goes beyond?
- Another idea: Sometimes a remoteproc is serving multiple discrete applications in user space & you don't want to cross the streams. Kernel User A loaded shouldn't be available to User B.
- Clement: Doing OpenCL over rpmsg. Not doing multiple applications, but can have multiple context. Think will need a way for multiple applications to co-exist.
- Maarten: How far do we want to define app services? Do you think Accelerators belong in this group? Accelerators are a bit different - they have a low-level specific standard API.
- Tomas: Good topic to discuss. OpenCL is pretty well defined. If we have energy around it.
- Bill: Depends on your definition of accelerator. We have built our OpenCL over these platform dev issues & had to solve many problems beyond the kernel (e.g. ELF relocation, multiple contexts). If we want to tackle this, we need to expand beyond what we do in the kernel…
- Arnaud: Offloading vs HW acceleration: If we want to interact w/ Linux driver, have to provide wrapper on rpmsg. If we want to process on some sensors w/ co-processors & have standard API.
- Clement: We have same kind of wrapper to use OpenAMP in more friendly way
- Let's see if more lifecycle, or needs a higher level interface. Or maybe falls a bit in both categories.
- Etsam: Commonly used application interface -> Ethernet may be owned by higher level OS & RTOS or baremetal wants to access over socket interface.
- Can intercept socket interface & translate into rpmsg calls.
- Can also enable cross-debugging. E.g. small CPU with RTOS/baremetal -> socket connection to higher level OS & connects to slave processor over rpmsg & can debug over Ethernet
- Maarten: Like that, makes sense. Leveraging existing API with another address family or mapping. Portability & re-use.
- Bill: Need to add rpmsg mode to socat. For Etsam's debug case, you could run web socket connection & tunnel it over rpmsg
- Maarten: next slide: Where is the biggest app services need?
- Fuchsia FIDL is BSD licensed & potentially ecosystem we could leverage for higher level RPC
- Would vote for Etsam's point of socket API
- Bill: Not suggesting this be tackled 1st & not familiar with some of these terms. What about connecting to information bus where you don't have to know/care where info is going?
- Maarten: Like Linux pub sub for information flow?
- Maarten: Do we want to wire openamp to Linux?
- Mathieu:
- Could use existing buses & change transport so it's just a message passing interface
- Remote file access: NFS could be re-used & change plumbing underneath to use message passing instead of network
- Whatever is chosen, keep in mind will require some modifications of OS services (Linux)
- Bill: Not sure how extensive that would need to be. Plan 9 FS works over virtio channel already. Already existing in virtualization environments & could be used here.
- Bill: Should we marry OpenAMP to Linux? No. But, many will use it with Linux, so some Linux-specific work should not be out of scope.
- Maarten: By leveraging user-level daemons, as NFS does (although they map into kernel), could sit outside the kernel. Could do open/close/r/w through daemon & have prototyped at Wind River. You have to go from ioctl to some canonical format & then convert to host OS format where the daemon runs.
- Clement: Could probably try to leverage the network. virtio-net. Will allow wide range of applications b/c sockets well supported on Linux. Could build on standard Ethernet w/ virtio-net.
- Maarten: Does it mean every runtime has network stack? Hard in resource-constrained env.
- Yes, that could be problematic
- Bill: virtio socket is raw buffer passing
- You could send messages & packets directly w/o encapsulation
- Maarten: Seems like there could be mapping between connected socket & rpmsg endpoint
- Bill: Could potentially extend existing virtio socket for mux layer. TI has socket-based interface to rpmsg that we've carried for several years. Has some warts. Suman could help write those down. Something like that or extending virtio socket interface would be interesting.
- Loic: Think we need both. Socket over virtio is a good thing, but in very very small system where can't multiply virtio link, then socket over rpmsg has good advantage w/ limited mem for shared link.
- Maarten: Don't need stack in that case?
- Loic: Using small driver on top of rpmsg & very small piece of code.
- Maarten: Open source or proprietary?
- Loic:
- Open source, think it's same driver between ST & TI.
- Depending on rtos or baremetal, may have some limitations on bind
- Can look for patch
- Agree, Suman should be in the loop
- Send us info to the list
- Bill: Are you talking kernel side or MCU?
- Loic: kernel. MCU is not based on openAMP.
- Virtio layer in openamp library is there & can be used by the MCU
- Do we want to present socket interface on MCU side or RTOS side & which socket layer do we want to integrate with. That gets kind of messy.
- Maarten: Think socket is API that ppl understand. Will allow us to build on top w/ existing middleware.
- Loic: Use on docsis SOC that runs on Cortex A side & the port was easy w/ socket w/ integrated modem & shared memory link. Socket interface could be good for application porting.
- Maarten: Good, will call it out as priority.
- Bill: What RTOS should we be targeting & who's responsible? FreeRTOS & Zephyr & TI RTOS & VxWorks each have their socket layer.
- Maarten: Good Q. Let's pick 1 so we have a working example & ppl can port it to their favorite. Wouldn’t suggest VxWorks b/c not open source. Probably freeRTOS or Zephyr.
- Makes sense. Bare metal as well.
- Maarten: e.g. newlib
- Good question, how to target baremetal.
- Thinking don't have a stack & want to use socket interface
- Maarten: Could provide openAMP socket lib that you include in your C file & no OS integration
- Etsam:
- Agree, don't have to integrate with socket layer out there. There can be a path for that.
- virtio-net on the MPU side -> Have to include other layers of comm stack
- Bill: 2 things -> virtio-net & virtio socket layer. Socket layer doesn't need.
- Maarten: Topic is going a bit deep, let's move it to mailing list.
- Maarten updated the slides: the ones in red are resonating the most
- Clement: yes
- Remote file access -> Would be nice if open close read write & also device files, not just mounted disk
- Bill: Think should look at plan 9 FS stuff w/ file access, FIFO access, device access. It's a file descriptor sharing scheme. But problem with that is happening at kernel level, so level of trust is same as kernel. If use a process, then you can apply restrictions.
- Maarten: Right, don't want remote runtime to be able to take down host OS
- Mailing list: Maarten wants ppl to subscribe themselves.
- We can broadcast a message to the TSC list for ppl who are interested to sign up
- Maarten: Is this timeslot good? Pretty well attended today. Do you want regular calls?
- Tomas: Initially to keep momentum up. Can see how much activity we have on list.
- Let's plan to have 1 in 1 month & can decide closer.
- No objections to this timeslot from anyone on the call.
- Maarten: Just b/c a PoC goes in a certain direction, doesn't mean that will be the end result
- Bill: Are you thinking patches to the list? Headline to list w/ a link?
- Maarten: It's open. How do you work in the mainline?
- Bill: Patches all go to the list. OpenAMP has done pull requests. Interaction there is a little less.
- Maarten: Think we could do a lot in app services without impacting OpenAMP b/c building on top. Maybe just small patches.
- Loic: Where will the code live for app services? Should we separate it?
- Maarten: Different repo
- Bill: agree
- Loic: Have to see how to create several repos under OpenAMP project & use GitHub for the review
- Bill: How do you get notified of PRs?
- Manju: You can do "watch". My view: I don't like GitHub PR mechanism. It doesn't fit with OpenAMP & kernel workflow of using mailing list.
- Maarten: For now, let's just see how things go & dial it in as we see.
- Ed: Workflow for OpenAMP is subject to change.