--
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/CAMkOBfsYtAPPf9D4dGPJPsFbhWZK6gQvLTawv%3Dwff89UCME0zg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CACr%3D8_NR%3DhNVjoXHHpJYK%3DxT7HVpsquKMt6icNbvJTW6Gd2M4Q%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CA%2BX8dX-xT0J_C0CQYiqnyif9S%2BwDu6vJaJvi0Wi%3DfWw15nQuNw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAFFy6-B6mLMmgYfb8ZonOAVmhRzm5Zx5706L3VSO5J1%3DdhcPRA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAH%2Bq2nwzTmdQCqWp0KgdmY0FRBwcXkNk1VZFDjuU2TYODCGDGg%40mail.gmail.com.
POR #1 — that's correct. We currently can't directly inject things into the incoming namespace, so we have a side-channel where we provide a clone of the exposed_dir to the driver using an offer:This is where I would like dynamic capability routing to help us. If the driver manager can specify the things we want to offer when we create the driver component, component manager can then make those available directly through the incoming namespace. Currently the things a driver component users in its manifest only come from what is offered to the collection.POR #2 — The POR is if you're a driver component, you expose a unified service to the collection, and you can then route that to the rest of the system from the collection, just as you would anything else in the component topology. This also aligns with how we use devfs today, where a driver directly exposes services to devfs, and doesn't rely on its parent driver to act as an intermediary.All this to say a driver component communicating with another component in the system, looks like any other component in a collection. However, we need unified services to make the exposing of a protocol/service from a collection sensible.As Suraj alluded to, there's issues of watching for service instances and exclusive ownership. Right now, it seems like we're leaning towards routing services to components that manage policy, like fshost, to then make smarter decisions about what to do with certain services.On Wed, 24 Feb 2021 at 12:15, 'Suraj Malhotra' via component-framework-dev <component-f...@fuchsia.dev> wrote:The plan of record for routing from the driver collection to non drivers is something along the lines of:
Driver manager will export a "service" such as `/svc/<SERVICE_NAME>/`. Devices will dynamically add service instances such as `/svc/<SERVICE_NAME>/<INSTANCE>/`. This is analogous to the existing system where driver manager exports `/dev/` and drivers dynamically add entries to `/dev/class/<CLASS_NAME>/`. You can probably attempt to route subdirectories of the exported `/svc/<SERVICE_NAME>/` directory to get a particular instance routed to a particular component in the static topology, but I imagine most often folks will do what is done today with /dev and only route a particular class, use a directory watcher to see all instances as they appear dynamically, and figure out which instances they want to talk to.
My understanding originates from the original go/unified-device-discovery design doc. Adding the driver moniker here seems like a bad idea as the client should not know what driver is implementing the service. In my example, <INSTANCE> should be dynamically determined by the provider of the service. For a network service, it could simply be MAC address, for a block partition, it could be the GPT UUID, etc. Ensuring that instance-ids don't conflict is a difficult problem I guess, but erroring out on conflicts or automatically adding a counter `-##` to duplicates would be simple solutions we could use for now.