--
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/CAMkOBfv2tdF3o4cFibG_GD4Vu1DeZhqGinXNFt4qXMv6dXP1pQ%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to drivers-dev...@fuchsia.dev.
I think "Drivers are components" is straightforward, but devices are messy, especially compound devices. Is a multi-port I/O device a single device, or multiple devices? (or is a single capability or multiple capabilities which are offered by the driver component?)Leaning harder into the I/O example: some multi-port I/O hardware changes shape based on how it's used. It might be multiple ports implementing different buses (SPI, I2C), or it might be a parallel synchronous bus (ie bit-banged). It may need to change which it is at runtime, too (I've built products that had to do that with I/O peripherals depending on what, exactly, was going on). There's a lot of I/O multiplexing...A less IoT-focused, but still I/O-ish example that I can think of, that's worth discussing is storage:
- raw device- block device interface- partition interface- filesystemThe raw device is a big composite that's exposed in a bunch of different ways by successive layers of drivers. Which I think maps well to the I/O port. There's a low-level hardware-specific driver that knows how to talk to the device over its bus, and drive the configuration registers, and then there are the higher-level "protocols" that can then be exposed. I2C and SPI might still be fairly hardware-specific in their implementation, but there could be a component which parcels out SPI ports (or onboard temperature sensors that are wired to the processor via I2C).
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAMoPQxFL-O%2BiGbmGZidrtWKGSHLTU54hb8kzNav976cZHE2RdQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAMoPQxFL-O%2BiGbmGZidrtWKGSHLTU54hb8kzNav976cZHE2RdQ%40mail.gmail.com.
Device is a really ambiguous term which honestly means different things in different contexts, they are similar, but not quite the same. In fact, we've straight up replaced the concept of a device with the term "node" instead in our FIDL definitions for the component based driver architecture.
If we look at our current usages of "device" in our existing driver framework, it more or less expresses this idea of something that takes one or more resources and transforms them into one or more resources. Those resources may be interrupts, regions of memory, spi devices, clocks, a partition, a microphone, etc. Most resources are exposed via a standard interface described by banjo or FIDL, but mmio and interrupts are notable exceptions. Resources exposed outside of the driver framework are only exposed as interfaces in the form of FIDL protocols.We have what I consider an elegant system for composing these resources together in a way other OS do not, and trying to model your understanding based on those OS may be confusing.
If a component (same cml) is loaded into the static topology multiple times, do you consider each "instance" a separate component?