-
Notifications
You must be signed in to change notification settings - Fork 291
TSC Meeting Notes 2021
Nathalie Chan King Choy edited this page Jul 23, 2021
·
13 revisions
- Bill Mills
- Tanmay Shah
- Maarten Koning
- Jeff Hancock
- Nathalie Chan King Choy
- Tomas Evensen
- Bruce Ashfield
- Loic Pallardy
- Stefano Stabellini
- Welcome Tanmay, introductions.
- Tomas: Heterogeneous end-to-end example (continued)
- Maarten, Jeff, Tomas: Inclusive terms (continued)
- What's our process to make changes to sensitive terms after deciding?
- Nathalie: Summary of website updates.
- Nathalie: When to have next call?
- Tomas to reach out on the TSC mailing list for who else is interested in going deeper into end-to-end example
- Nathalie: Send a doodle poll for end-to-end example call in 2-3 weeks to Tomas, Tanmay, Bill M, Kumar, Dan Milea, Arnaud, Jeff
- Define the use cases for replacing master/slave terms and post to TSC list for further discussion
- Maarten: app-services
- Bill: Lower-level
- Nathalie: Send Doodle poll for early September call
- Nathalie: Include outstanding governance items on next TSC agenda
- Link to recording. Please download a copy to view it sooner than later, before the recording expires.
- Introductions
- Tanmay will be Xilinx assignee to Linaro
- 8 yrs in embedded
- Previously in multimedia domain
- Recently joined Xilinx platform management team
- Nathalie
- Previously 11yrs at Xilinx in System level testing & System software. Had managed PetaLinux, QEMU & early OpenAMP team.
- Now doing Program management in Xilinx Open Source Program office
- Bill Mills from Linaro
- Currently at Linaro: LEDGE, LITE
- Previous life: 25 yrs at TI
- Bruce at Xilinx
- 3.5 years at Xilinx
- Maintenance work on Yocto project
- System DT: Wrote Lopper
- Jeff from Siemens Embedded (formerly Mentor)
- Started in 90s at Single Step Debugger
- Got acquired by Wind River
- Went to Renesas for Automotive
- Now Product manager for Nucleus RTOS & Multicore Framework (commercial OpenAMP w/ extra features)
- Starting to certify a certifiable version of Multicore Framework
- Maarten at Wind River
- Real-time & Safety runtime integration
- WR Linux, VxWorks RTOS
- Interoperability & resource sharing: Looking to build on top of OpenAMP -> app-services working group
- Stefano from Xilinx
- At Xilinx 4 yrs
- Xen Hypervisor development
- Working on System DT spec -> system-dt working group (call tomorrow)
- Tanmay will be Xilinx assignee to Linaro
- Heterogeneous end-to-end example (continued)
- Similar idea to what Linaro is also working on (Francois, Kumar)
- Will it be 1 project, 2 projects?
- Objective for this meeting: Who are interested in going deeper in what we are going to do?
- Tomas, Tanmay, Bill M, Kumar, Dan Milea
- probably Arnaud (confirm when he's back from vacation)
- Include Jeff for now. Jeff to check w/ Etsam and others.
- Who else wants to be part of core group that defines what we do?
- Who wants to be associated?
- Tomas to reach out on the TSC mailing list for who else is interested in going deeper into end-to-end example
- Tomas shared strawman proposal: Link to PDF snapshot
- Need to understand where we have gaps
- System DT is an important part of it
- Bruce: Lopper/Zephyr collaboration:
- Lopper is embracing some Zephyr tools: Can use their dtlib as pure Python parser, so don't need to use dtc
- Working to pull together reference System DT for various boards
- Having an end-to-end demo will help us reach out to more silicon & RTOS vendors
- Automotive could be interesting: Tanmay's graphics background, Siemens Embedded has Autosar experience
- Bill: Nordic's use case is MCU-MCU, which may be broader use case.
- Tomas: For future: 2 RTOS could be interesting. Most common case is Linux as big OS + RTOS.
- Loic: If can have same system DT configure the 2 RTOS b/c shows w/ same hardware or system config we can generate the right file for the different HW environments, with the same Linux managing the several sources, your co-processor can run different RTOS ecosystems
- Bill: For big demo use case: 1 Linux, 2 control processors with their own RTOS that communicate w/ each other
- Tomas: Could have R5 (split), Microblaze in Xilinx device
- Xen could be good hypervisor starting point: Applications don't change that much - how to build Xen & configure w/ DT. Stefano can help.
- Xilinx QEMU team can help, but probably won't call into the meetings. Will invite Edgar to at least 1 of the calls. Ideally, would like to use upstream QEMU, beyond Xilinx QEMU.
- Bill: When we get into this more, how to execute? e.g. virtual sprints. We're running out of runway to demo at Linaro Connect LVC21F. Shooting for end of year for this. Maybe could sign up for Linaro Connect demo Friday.
- Nathalie: Send a doodle poll for end-to-end example call in 2-3 weeks to Tomas, Tanmay, Bill M, Kumar, Dan Milea, Arnaud, Jeff
- Inclusive terms
- Siemens: haven't blessed everything, but have snip of relevant terms to OpenAMP
- Have been using remote for a while instead of slave but kept using master
- Xilinx focusing on master/slave, whitelist/blacklist, male/female connectors
- WR is mapping terms depending on the context & the guidance is loose. The point is to just remove master/slave.
- App-services very linux-centric w/ the daemon running on Linux as resource owner. The users of the services are the auxiliary doing runtime/safety. Would like to see a term for the host OS where it implies that it's the resource owner. Gets complex when safety OS is the auxiliary, even though it's the resource owner for a firewall, network service. Not sure if lifecycle is the right way to think of it.
- Linaro: No concrete discussion. OpenAMP largely based on virtio, so aligning to virtio should be a consideration
- Driver/device
- Host/guest don't really work great b/c that makes the remoteproc the host which is counterintuitive
- Agree it's context sensitive & main point is to eliminate master/slave
- Virtio & Xen terminology are different - messy
- Xen: Back end owns the resource, Front end connects to it. Clashes with virtio. Resource owner as driver domain b/c is physically driving the device.
- Virtio: Driver for front end.
- In future work (e.g. end-to-end example) we should avoid using terms like master/slave
- For OpenAMP, we should decide what we want to do
- Remoteproc master/slave
- RpMSG who owns buffer is different from primary for remoteproc - can be confusing which is master/slave
- Xilinx, WR no strong preference
- Resource owner
- Lifecycle instantiation
- Remote doesn't make sense in System DT b/c remote compared to what? Primary/secondary works better here.
- Maarten: Server as bigger/provider/owner. Client as user/smaller. Works for file system.
- Bill: I2C device on remoteproc is not intuitive. Prefer front end/back end for device sharing model, similar to Xen.
- With front end & back end you have to define it, so that can be a good thing.
- Bill: In OpenAMP, that would be remoteproc as server
- Tomas: App services using virtio - could use server/client there. For remoteproc to start up something else could use a different term.
- Bill: Leaving remoteproc out for now. Looking at device sharing. Remoteproc as back end works well & shows difference in use case.
- Linux + RTOS
- Do we need name for primary OS & secondary OS? Will really need to define.
- Maarten: Thinking of RTOSes as auxiliary OS for Linux, rather than primary OS b/c amt of SW that ppl don't want to port to RTOS. Linux-first approach: OK to call Linux the primary. RTOS vendors might not like their product being called secondary all the time.
- Bill: Depends on context and on role. System init vs device sharing: Who's primary & secondary changes.
- Tomas: Could use different words for big OS & small OS vs. providing of services.
- Maarten: e.g. Publisher/provider, subscriber/user
- Bill: Provider & user are more clear than front end/back end. Initiator, responder for communication links.
- Maarten: Provider suggests you own the resource & you provide it to users.
- Bill: Boot flow: Initiator & responder
- Next steps:
- Here's a starting list of use cases:
- What we call the operating systems (Candidate: primary/secondary)
- Communication (Candidate: Instantiator/responder)
- Services (Candidate: Server/Client)
- Define the use cases and post to TSC list for further discussion
- Maarten: app-services
- Bill: Lower-level
- Here's a starting list of use cases:
- Siemens: haven't blessed everything, but have snip of relevant terms to OpenAMP
- Next TSC call: Early September
- Nathalie: Include outstanding governance items on next TSC agenda
- Tomas Evensen
- Nathalie Chan King Choy
- Dan Milea
- Arnaud Pouliquen
- Jeff Hancock
- Loic Pallardy
- Stefano Stabellini
- Etsam Anjum
- Tomas, Dan, Jeff: Inclusive terms
- Tomas: Standardization
- Maarten sent to list what WR has
- Mentor Embedded (-> Siemens Embedded since January) is working on a document of recommendations
- Various LF members are part of https://inclusivenaming.org/
- Nathalie: LVC21F CFP - Does OpenAMP Project have topics to submit? Deadline is July 13, 2021
- Event is Sept 8-10, virtual
- Kumar, Stefano will try to join last 15 minutes: Tomas, Kumar: Heterogeneous end-to-end example
- Jeff to send Nathalie the Siemens logo [DONE]
- Nathalie: Check w/ Stefano if anything related to DT could make sense to present
- Tomas, Nathalie: organize a kick-off meeting for end-to-end example project
- Tomas: Call for interest to see if can harmonize virtio (both leadership, resources).
- Loic & Stefano to discuss virtio & Stratos alignment further.
- Nathalie: Schedule next OpenAMP TSC for end of July
- Link to recording: OpenAMP TSC - June-20210615 1706-1
- Not sure how long before it gets auto-deleted, so please download the recording in the next few weeks if you want to get caught up
- Inclusive terms
- Tomas: OpenAMP uses master & slave in different ways, so might have different end states for the different use cases
- Remote proc
- Who owns the buffers
- Maarten had sent to the TSC mailing list w/ different use cases for master/slave & what to replace
- For high availability: active/standby
- For clocks: primary/secondary
- For virtualization: host/guest
- For services: server/client
- For notifications: publisher (or provider) / subscriber
- For other scenarios: initiator/responder
- Xilinx: Trying to change forward-looking things
- Need to align w/ Arm for AXI
- At this point, have suggestions & not implemented yet
- Wind River
- Would be using "main context" (instead of master context) and keep "remote context"
- Siemens
- We have been giving guidance
- Siemens as a whole is going through the endeavor. A lot of products, so taking longer than originally hoped. Waiting for 1st draft to give feedback on.
- Would like to follow industry terminology
- Looking at enabled/disabled b/c disabled has negative connotation
- ST
- Waiting for some change from IEEE to change I2C spec which has master/slave before we change
- Starting to change some vocabulary, but don't have guidelines to share today: Main/secondary, Initiator/responder
- Also have to look at French inclusive language
- One good proposal for OpenAMP: main/remote instead of master/slave
- Are any OpenAMP participants taking part in https://inclusivenaming.org/ ?
- Tomas: OpenAMP uses master & slave in different ways, so might have different end states for the different use cases
- Linaro Connect LVC21F CFP
- Not sure if we will have enough on the end-to-end topic by September
- Last LVC21, we covered 4 perspectives on DT (Bill, Kumar, Andre, Stefano)
- Nathalie: Check w/ Stefano if anything related to DT could make sense to present
- End-to-end example
- New assignee b/c Ed left Xilinx. Maybe can get going w/ the project in July.
- Would like to move from Xilinx to upstream QEMU for CI loop & end-to-end - can get some help from a Xilinx QEMU maintainer
- Lopper: working on converting to what Zephyr needs
- Figure project could get started in July
- Open area where we could use resource w/ Zephyr expertise: Would like to get Zephyr up & running on various boards + KVMtool from WR
- Some work done by WR for serial IO, virtio
- Tomas, Nathalie: organize a kick-off meeting for end-to-end example project
- ST has some development working w/ Zephyr RTOS. Some customers who use Zephyr on ST platform.
- How to harmonize virtio in original OpenAMP under rpmsg + what came in via WR app-services contribution (BSD) + others working on
- Stratos project doing some work with Zephyr for hypervisor for automotive/embedded w/ security properties
- Some ppl, incl Arm, working on in Xen community
- Fair to have 2 communities/groups, but right now we have a dozen
- Default: Type 2 hypervisor: Virtualbox, kvm
- Other: Type 1: OpenAMP in this category
- There are some deep technical questions & unclear how to align. Complex.
- WR implementation based on memcopy by guest to/from pre-shared memory region
- Stratos aiming for memcopy into larger ring itself. Virtio ring to be expanded. No pre-shared region.
- Xen looking at enabling, but 3 virtio talks at Xen summit a month ago: Radically different approaches
- The commonality is that they're all trying to re-use most of the drivers. Maybe small changes to spec or bus driver/layer.
- Options: Could create group for all virtio. Could create group for embedded use case & hypervisor discussed in Linaro. Too hard & punt.
- Expect there will be 2
- Hypervisor based, but not Type 2. Not likely to work for OpenAMP.
- Memcopy based & almost no hypervisor. Hypervisor neutral & may work for OpenAMP -> Could make sense to unify these efforts across domains.
- Stratos
- WR
- Qualcomm posted some pre-shared memory approaches to LKML
- WR interested in aligning to a standard. Right now, still exploring & created POC. Trying to get the changes into a spec or align to an existing spec. Currently, no spec to align to.
- Vision of OpenAMP is to standardize at different levels. Becomes harder w/ different implementations.
- Siemens look at virtio for multi-OS offerings. Makes sense to have standardized back-end implementation w/ proper porting layer.
- Using with OpenAMP
- With I/O virtualization
- Automotive use cases (AutoSAR)
- Not sure if can do portable implementation w/ Linux, but with virtualization
- Even if we couldn't share entirely the approach (think we can), there is benefit to push forward virtio model that doesn't require Type 2. Causes problems in Linux kernel that is hard to fix. If could at least make the use case more widely understood, would be easier to upstream bug fixes to Linux.
- ST platform is smaller, so not targeting virtualization. Following the discussion on virtio though. Services need to share between main & secondary processors on top of virtio that we don't have on top of rpmsg. There is work to do for standardizing services to be able to multiplex on top of other things. Need to consider multiprocessor systems w/ limited memory. When to move on top of virtio & when on top of rpmsg.
- OpenAMP really looking into resource constrained devices.
- Hypervisorless virtio, embedded hypervisors
- Next: Consider starting working group on this topic. Would need someone who can drive it. Let's start with a call for interest to see if we can harmonize it.
- Tomas: Call for interest to see if can harmonize virtio (both leadership, resources).
- Loic's concern is that what gets merged in the kernel is only based on 1 use case, which would create a legacy and then redesign would be complicated. Good to discuss w/ Linaro & see if they want to extend scope of Stratos.
- Loic & Stefano had to stop attending Stratos calls since beginning of this yr b/c of meeting conflict.
- Loic & Stefano to discuss virtio & Stratos alignment further.
- OpenAMP is an important context b/c also get perspective of RTOS vendors.
- Next meeting: We will have the new Xilinx assignee & can talk more about the end-to-end example. Target end of July.
- Stefano Stabellini
- Arnaud Pouliquen
- Bill Mills
- Ed Mooring
- Etsam Anjum
- Grant Likely
- Ioannis Glaropoulos
- Loic Pallardy
- Maarten Koning
- Tomas Evensen
- Nathalie Chan King Choy
- 1 min: Maintainer news
- 10-15 min: Tomas, Kumar: Heterogeneous end-to-end example
- 3 x 5 min: Stefano, Bill, Maarten: working group updates
- 5 min: Nathalie: LVC21F CFP - Does OpenAMP Project have topics to submit?
- 10 min: Maarten, Jeff, Tomas: Inclusive terms
- 10 min: Tomas: OpenAMP resourcing needs for various upcoming initiatives
- Stefano & Nathalie: set up next System DT call (aim for mid-June)
- Stefano: Send out slide from today Slide here
- Maarten: Send out slide from today Slide here
- Maarten: Schedule meeting on the Zephyr work
- Tomas, Bill: discuss resource plan in another meeting soon w/ Kumar (this week)
- Nathalie: Set up follow-up TSC call in a couple weeks
- Link to recording (Not sure how long before it gets auto-deleted, so please download the recording in the next few weeks if you want to get caught up)
- Congratulations to Ed on retirement. Last day at Xilinx this Friday & has offered to continue as a maintainer.
- Xilinx is discussing internally to determine LITE assignee successor
- Stefano: System DT update (slide here)
- Did March LVC21 presentation on DT state of the union, including System DT
- Had System DT call earlier this month
- New developments
- Remoteproc
- Made sure the plumbing works from system DT
- System DT description is smaller b/c multi domain & multi cluster
- Lopper plug-in to generate traditional remoteproc binding from System DT info
- Biggest new development: Hierarchical domains & access flags
- There can be many domains (e.g. on different processors, with hypervisor). Best way to describe is in a hierarchical way. (e.g. VMs as domains under Hypervisor domain)
- Benefits:
- Closer representation to reality
- Access flags are domain specific b/c depends on the technology (e.g. flags on Xen domain different from flags for FreeRTOS running on Cortex-R)
- Remoteproc
- Lopper updates
- YAML as way to express info as input to Lopper
- Easier for humans to read/write than System DT format
- New DTS parser coming from Zephyr
- More lops & hooks for adding plugins
- Backends (incl. YAML)
- ReST API so you can invoke Lopper programatically
- Plugin for Xilinx CDO generation as example of plugin for generating other boot-time scripts
- YAML as way to express info as input to Lopper
- Stefano & Nathalie: set up next System DT call
- Bill: What's plan for System DT spec?
- Stefano:
- For now, we're putting the description we have in the Lopper repo in .rst files (similar to DT spec)
- Some changes (not many) will need to go to main DT spec. Small but impactful.
- Domains could be in main DT spec or could go elsewhere. Self-contained & a bit separate.
- Loic: SystemDT & Zephyr?
- Stefano
- Bruce & Kumar have a plan
- We sent a small system DT example with a couple domains (one of which is Zephyr) to Kumar for him to try to integrate it
- Lopper adding alternative DTS parsing: Pulling the Zephyr parser in Lopper. Idea is to merge the 2 efforts.
- Loic: So, no firm commitment from Zephyr community to move on System DT?
- Stefano: Not sure. Kumar is main point of contact.
- Loic: Now is currently more evaluation & no strong decision?
- Tomas: More similar to Linux, DT is not changing for that. Start state: Can use Lopper & create a DT for Zephyr. Optional if you don't have multiple clusters.
- Loic: Even without multiple clusters, you can use Lopper to transform DTS file to avoid duplicating different tools. MCU boot & TF-M, with Cortex-M with Secure/NS have problems describing the IP. Know Linaro working on TF-M integration w/ Zephyr. Would be good to have common system descriptions for the different SW components. Difficult for SoC system to embed DT, so if Zephyr is moving on that, can see others to move.
- Tomas: Would be ideal. Intent is to have 1 way of doing it.
- Bill:
- Break into 2 problems:
- System DT part.
- Whether you are consuming system DT and know which node you are, or you generate a node-specific DT & how do you update code to match.
- Today, can do System DT processing & deliver DT to Zephyr
- How do we do same thing with Trusted Firmware or OP-TEE, etc?
- Zephyr looking at how to make what they do more portable to other projects, whether or not the input is System DT is orthogonal
- Break into 2 problems:
- Stefano: Right now more looking at reusing Lopper to manipulate DT. Lopper as a framework, can add a lot of value. Lopper is more flexible than what Zephyr currently has.
- Maarten: App-services update (Slide here)
- Goal: Enable multi-OS systems to achieve Linux-based application-friendly resource sharing & IPC on multi-core HW.
- Approach:
- Want to reduce learning curve: use existing APIs, drivers, etc.
- Provide unifying way to share resources across different deployment architectures & do IPC across
- Path for mixed criticality & safety
- Decisions & Next steps (refer to the slide)
- Tomas: Ties in well to end-to-end example
- Bill: You ran demo with RTOS + Linux. kvmtool up on OpenAMP GitHub. RTOS not yet visible to everyone?
- Maarten: We implemented it with VxWorks & Linux.
- Bill: Can I do it without paying a VxWorks license?
- Maarten: There are non-commercial offerings from labs.vxworks.com.
- Demonstrated initially with VxWorks
- Want to get the Zephyr part done, so that others can contribute. Did BSD virtio port. Open sourced the user level daemon based on lkvm. Demonstration & validation activity with VxWorks to prove it out & show the value. Understand that we need to get it onto Zephyr so that others can contribute.
- Would like to try to get some OpenAMP reserve funds to accelerate the Zephyr aspect.
- Loic: New virtio framework for Zephyr instead of reusing virtio framework in OpenAMP library? Both are based on FreeBSD implementation. Zephyr has virtio framework, but it's already part of OpenAMP library.
- Maarten: Not aware of other Virtio framework for Zephyr before the one that we did.
- Maarten: Researcher in Japan did some work based on Linux GPL implementation of virtio and did some tests, but can't release on Zephyr b/c license used for that code.
- Bill: True. OpenMAP has been part of Zephyr for several years. Virtqueue is part of the rpmsg stack. With your contribution, there is a duplication of the virtqueue level.
- Maarten: If derived from BSD, would be great to reuse that code. We took FreeBSD virtio code & built it for Zephyr on framework side. We didn't look at optimization/duplication & that work hasn't happened yet. Would be great to have some work on optimization.
- Loic: OpenAMP virtio will require some modification of virtio service layer in OpenAMP. Would be good to port on several OS with OpenAMP library used for virtio instead of duplicating virtio in each project.
- Maarten: We should have meeting on the Zephyr work
- Tomas: Potential task could be to harmonize the virtio solution in end-to-end example
- Bill: Need to discuss scope of app-services
- Good to focus on: Using hypervisorless virtio as a transport
- Some of the other parts intersect rpmsg, remoteproc & system DT
- Still have yet to demonstrate the full flow in a truly open source manner.
- Concern that scope is starting to encompass the other parts of the project & not fully open source yet.
- Maarten: Agree. We should be focusing on the all open source implementation w/ Zephyr
- Have been leveraging some efforts at WR
- Demo would be contingent on dependency of Zephyr investment. Would like this group to see how we can resource the open source demo.
- Bill: Engagement on proprietary is perfectly fine. But want to enable community to measure what you're demo-ing. When at TI, didn't use OpenAMP, but invested in the open source to prove out concept. Would like to understand what remains to be resourced.
- Maarten: We did the framework and console. You need the 9p filesystem protocol and you need the vsock: those are both virtio-specified drivers that don't exist for Zephyr that need to be ported from another runtime. We were focusing on the user-level daemon based on lkvm to terminate the hypervisorless virtio and open sourced that. We did the framework for Zephyr & open sourced that and been contributing into Zephyr as well.
- Bill: Can we run a fill demo with just console today with Zephyr and Linux?
- Maarten: No hypervisorless virtio yet in Zephyr. There's just Zephyr virtio framework. Need MMIO driver & interrupt going across to Linux.
- Bill: openamp-rp update has been posted to list
- New openamp & libmetal library versions released
- Significant progress on kernel upstreaming. Slowed down a bit b/c have worked through backlog of high-priority stuff. Xilinx R5 stuff important & still outstanding.
- Starting discussion on some PRs pending with big changes w/ wire protocol changes
- Thinking about namespace 2.0 proposal, future proof & backward compatible
- Resource tabling enhancements that Arnaud is working on, but need to define current spec for resource table, so can make proposal for the enhancement.
- Negotiating message size dynamically at startup time
- Future work:
- We don't have a good spec for what the wire protocol is & need one
- Right now we just look at what Linux is doing & be compatible
- Once we have the spec, then we can have wire protocol spec changes
- At the same time, want to tackle the OpenAMP doc infrastructure. Will be Sphinx-based. Won't be as fancy as Zephyr or Yocto Project, but they are good examples to look at. Would like to have demo of the doc infrastructure by next TSC (e.g. top level table of contents, how to generate PDFs).
- Low hanging fruit w/ CI
- Demo: Rpmessage with 2nd virtqueue doing a mainstream virtio protocol. I2C is a decent example in upstream kernel.
- Different from Maarten's primary use case for remoteproc (them using services from Linux), this would be Linux using services provided by remoteproc.
- But there's a lot of commonality, so would be good to collaborate w/ app-services
- We don't have a good spec for what the wire protocol is & need one
- Tomas: End-to-end example (covering all the OpenAMP sub groups)
- Link to strawman proposal in Google Docs
- Linaro LITE have been talking about heterogeneous example which is very aligned with what we are trying to do
- Running Linux on Cortex-A cluster, maybe add Xen later. Cortex-R or M cluster with Zephyr as RTOS.
- Initial platforms to consider:
- Ultra96 or Xilinx SOM (A53 + R5)
- ST stm32mp1 (A7 + M4)
- QEMU
- Want to be able to measure throughput & latency
- Would like to show configuration w/ System DT, lifecycle using remoteproc, low-level messaging, app-services
- First: Enumerate the tasks, then look at resourcing.
- Would be great if LITE can do the project management, if aligns sufficiently
- Still at concept level & invite others to chime in
- Maarten: Like resourcing app-services so we can have OSS implementation
- Bill: Timeframe?
- Tomas: Hope for end of year, but depends on what resources we can get.
- Bill: Linaro Connect, ELC, Plumbers would be good place to show subset of progress in fall
- Tomas: Plan to discuss more with Kumar
- Tomas, Bill: discuss resource plan in another meeting soon w/ Kumar (this week)
- Nathalie: Set up follow-up TSC call in a couple weeks