If you don’t write drivers feel free to disregard this email.
As part of the Drivers as Components effort, drivers will soon have component manifests. The Driver Framework team is working hard to make sure that this transition is barely noticeable to driver authors. You will likely just see some extra build rule information show up in your BUILD.gn files.
Here is an example of a driver transitioning to having a component manifest.
The fuchsia_driver_component build target will automatically generate the CML file for your driver! What does this CML file look like? Like this:
If you wanted to, you could use a normal fuchsia_component target and write the CML out by hand. (Using the fuchsia_driver_component template is much more convenient for now though).
Although drivers are getting component manifests, they are not currently components. If you add any capability fields to this manifest they will not be hooked up to anything. This is simply an initial transitioning state to drivers-as-components.
The Driver Framework team will be going through and transitioning all 301 driver_module targets that live in the build. If you’re adding any new drivers, make sure that you’re using a fuchsia_driver_component target (The fx create driver command will take care of this for you!). We will also be adding a build-time check that all drivers under //bundles:drivers-build-only include a component manifest. So when you add your driver to that bundle, we will make sure that you’re not going to get hit by the footgun of including a driver without a manifest.
If the transition causes your drivers to have some awkward build target names (e.g: “my-driver-driver”) feel free to fix them up in a CL. You will just have to make sure that the build is depending on the fuchsia_driver_component rather than the driver_module target. For an example of how this is done see //tools/create/goldens/my-driver-cpp.
Please feel free to ask any questions about this transition! Thanks for reading and happy programming!