(Core) Manifest shards are sharp!

[Justin Mattson]

In doing something I discovered how core shards contributed to capability routes not getting updated. The short story is as a component moved to v2, core shards weren't updated because, how would one even know about them!? The problem was masked by capability washing through appmgr and sysmgr.

Any ideas how we can make core shards more visible? Or perhaps provide a reliable CLI incantation to find all of them?

Cheers,

Justin

[Shai Barack]

Good point about capability routes getting watered down through the appmgr realm and back. Really hinders our analysis capabilities.

--
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/CA%2BX8dX_3_aBmfa9NzMMqA93Ht87ytpb%2B5J3ODP5%2BukZX0r6%2BhA%40mail.gmail.com.

[Justin Mattson]

The only thing I can think there is some sort of warning about "hey appmgr seems to be use and exposing this thing", but that would very much be one-off because it might be totally legit for some components to use a capability and then expose the same one.

[Shai Barack]

Bespoke yet immensely useful maybe.

By my count there are 45 capabilities coming out of the appmgr realm.

[Derek Gonyeo]

I gave core shards their own list in the product GNI files to make them as visible as possible (it's a small, independent list, instead of needing to dig through the package sets and their dependencies like sysmgr configs). It's clearly not perfect though :)

I'm not a GN expert, but if there were a GN incantation to print out the contents of core_realm_shards then it could be used to show you the set of shards included on a given product. Also after building, the post-merge version of the core realm's CML can be found at ${FUCHSIA_OUT_DIR}/obj/core.cml

As far as avoiding issues hidden by capability routes through appmgr, I wonder if we could have appmgr panic if it sees an incoming service for the sys realm include something that is also in sysmgr's svc directory. It would be a signal that the origin of the capability is muddied, there are alleged providers in both the modern and legacy stacks.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAK0PkCEd4MnCAEKjG_zM6PL6Q3K3y0CncneNGa2vh9tNPeP%2B3w%40mail.gmail.com.

[Shai Barack]

You could add a print statement to a gn/gni file and then `fx gen` and you'll see it printed.

https://gn.googlesource.com/gn/+/refs/heads/main/docs/reference.md#func_print

[Gary Bressler]

Should we update the migration guide to remind people that any routes from appmgr in `core.cml` (or any of the shards) need to be updated when a component is migrated?

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAK0PkCHwP4dmpjcp%2BdgC6xk3cqgxhYtYUEM8gqFsSH-1F7Pupw%40mail.gmail.com.

[Ben Wright]

If you broke the backwards expose out of appmgr scrutiny would catch it in CQ. So there are some safe guards, but technically looping it through appmgr is valid so it didn't complain. 

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAK1yh2%3D0pN2t%3DnBgswXemg641YMxR2EMuFbj8XC9k%3DjWRA%3D7MQ%40mail.gmail.com.

[Aaron Wood]

We can add a few GN arg controlled print statements for debugging various lists in the product assembly:

fx set ..... --arg=print_core_shards=true --arg=print_base_package_labels --arg=print_....

and then it would dump out those lists on every GN run.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAK0PkCHwP4dmpjcp%2BdgC6xk3cqgxhYtYUEM8gqFsSH-1F7Pupw%40mail.gmail.com.

[Justin Mattson]

Do I understand correctly that the suggestion is we could add a GN arg that in core_shard.gni would be checked, and if so, the path to the shard would be printed? If so, this seems like a feasible thing we could add to the migration guide and say "run your `fx set` with this arg, observe the paths printed, and check them". This adds a somewhat unfortunate level of burden, but seems better than the alternative.

[Aaron Wood]

I'd use `fx args` to just add the var, instead of dealing with `fx set`, but effectively yes.