openbmc/docs/hw-vendor-repos-policy.md

19 OpenBMC architecture (bitbake, d-bus, phosphor-dbus-interfaces, ...).
25 Both hardware-specific and vendor-specific repositories should meet the
36    - Determination made by the TOF
37    - Reference: "Create a new repository" TOF [process][tof]
45 1. The repository depends on other OpenBMC-hosted repositories
53 If a recipe is created within OpenBMC (in any meta-X layer) to point to an
57 1. It should meet all of the quality-based requirements for hosting a repository
63 Note that when a recipe is non-OpenBMC specific, but useful to OpenBMC, it
64 should be pushed upstream into meta-openembedded.
71    - For example, PECI, FSI, hardware diagnostics (specific to the processor)
87 A vendor-specific feature is defined as one of the following:
89 1. A vendor-specific data format or protocol
90    - For example, a dump collection of the host firmware, or a special format of
94 To add a vendor-specific repository to OpenBMC, it should meet the following
97 1. It consumes OpenBMC D-Bus APIs
98    - This indicates a synergy between this feature and OpenBMC
114 is why OpenBMC has a openpower-occ-control repository.
118 why OpenBMC has a peci-pcie repository.
120 The goal of this document is to clearly state the requirements and expectations
141 - A Hardware specific feature (implementation for a driver, support for
143 - Support for a vendor-specific feature. (OEM extensions, debug APIs, Redfish,
152 ensure a solid code base for others to use, and sets a certain standard for
171 In a perfect world, only hardware-specific features would be in the meta machine
182 [upstream]: https://github.com/openbmc/docs/blob/master/kernel-development.md
183 [tof]: https://github.com/openbmc/technical-oversight-forum/issues