--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "component-framework-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to component-framewo...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAK0PkCHhQQxekVUy%3D5iL%3DU5ZyRbyhNzNxq8ELQTwb2AvWT1p1g%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAK1yh2kEm-8RxzeCvQWB3q3ZOe-QG39TbGnY_Ov21HA%2BuN4MMw%40mail.gmail.com.
That still leaves open the problem of how to vary subrealms, like network.cml (which isn't variable yet but is likely to be at some point). At least to start off, we could try to solve that by defining different packages for the network realm and varying core to select which network.cml package is included.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAK1yh2kZw8mEZw%2BP8%2BTaOqKOxwqed-98S1OG0CMZ_WQ4G1sHsw%40mail.gmail.com.
I don't think an architecture that merges appmgr with core is something we need to commit to long term, but it could be an answer for now if we accept the constraint that RFC-0089 may only be applied to core.In practice, core and appmgr are closely coupled, since together they act as the system's nexus of capabilities.
It's pretty uncommon to have a protocol that is only used in v2, and as the migration proceeds it will become less and less common to have a protocol only used in v1. Merging them into the same component would be a reflection of this reality. Topologically, it has basically isomorphic semantics.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAP%3D28ce4ksGwC%2BxX1t_iQFM9yxpnqhhQCq8VoUphy-pt4gkxOg%40mail.gmail.com.
I think Adam's idea sounds promising, but I'm somewhat fuzzy on how it would work. The current architecture bakes in the assumption that appmgr is a singleton. In particular, there's a bespoke integration between diagnostics platform and appmgr. The only place we create a separate instance of appmgr is a couple integration tests.
One idea is to have a single instance of the appmgr runner, but multiple components using that runner -- maybe this is what you had in mind?
Each 'v1 island' is a v2 component that corresponds to a sub-environment, e.g. `sys`, `modular`, `test-env`.Open question: how do the v1 environments get assembled in this design? Are they a flat hierarchy under `root`, and the routing between environments happens through v2?
Or is it possible somehow to declare a v1 environment hierarchy in the manifest somehow?
Yes -- possibly, a component representing an environment within appmgr runner. There could be either one per test, or one nested under test_manager that creates sub-environments for each test.On Fri, Jul 9, 2021 at 9:44 AM Shai Barack <sha...@google.com> wrote:The idea being a nested appmgr in mixed test environments? Then yes, very interesting.On Fri, Jul 9, 2021, 12:19 PM Gary Bressler <g...@google.com> wrote:+crjohns and +yeg because I see applications of this idea to sessionmgr and hybrid testing. The current plan of record is to route the fuchsia.sys.Environment protocol from appmgr to the v2 realm. In a hybrid test, this means that a non-hermetic test gets services from two places: for v1 components, from sys, and for v2 from test_manager. If we created a sub-environment as a v2 component we could avoid the need to route the Environment protocol and route the same bundle of capabilities to the v1 and v2 environments.On Thu, Jul 8, 2021 at 5:16 PM Adam Barth <aba...@google.com> wrote:On Thu, Jul 8, 2021 at 10:56 PM Gary Bressler <g...@google.com> wrote:I think Adam's idea sounds promising, but I'm somewhat fuzzy on how it would work. The current architecture bakes in the assumption that appmgr is a singleton. In particular, there's a bespoke integration between diagnostics platform and appmgr. The only place we create a separate instance of appmgr is a couple integration tests.We used to run many copies of appmgr. I'm not too surprised to learn we've grown a dependency on it being a singleton, however. From what you've written, it sounds like they might be difficult to untangle.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAK1yh2njX5mMD1ZjpS_KzPC%3DHPkfHkN8ACSi1fUkg3cDbF5cgQ%40mail.gmail.com.