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

1 # Hardware Vendor Repository Policy
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.
66 ### Hardware Specific Feature
68 A hardware vendor feature is defined as one of the following:
70 1. A function that is specific to the vendor hardware
71    - For example, PECI, FSI, hardware diagnostics (specific to the processor)
72 2. A device attached to the BMC (MCTP/PLDM/I2C/...) that is specific to the
73    vendor which the BMC must interact with
75 To add a hardware specific repository to OpenBMC, it should meet the following
78 1. If it requires specific kernel APIs, they are available or in progress via
81 Some hardware vendor features which have no real synergy with OpenBMC, for
85 ### Vendor Specific Feature
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
92 2. A function that requires a specific hardware vendor feature
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
103 specific hardware families. For example, [OpenPOWER][openpower] was one of the
109 not always possible due to specific features or functions only provided by
114 is why OpenBMC has a openpower-occ-control repository.
118 why OpenBMC has a peci-pcie repository.
121 for hosting a hardware/vendor specific repository within the openbmc github
139 Within OpenBMC there are two areas of "vendor specific" repositories:
141 - A Hardware specific feature (implementation for a driver, support for
143 - Support for a vendor-specific feature. (OEM extensions, debug APIs, Redfish,
171 In a perfect world, only hardware-specific features would be in the meta machine
172 layers, and vendor specific features should be in distro features. OpenBMC is
178 vendor specific features and also as a reference for the TOF team to review when
179 assessing a request for a vendor specific repository within OpenBMC.
182 [upstream]: https://github.com/openbmc/docs/blob/master/kernel-development.md
183 [tof]: https://github.com/openbmc/technical-oversight-forum/issues