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

12 a request for a new repository or a bitbake recipe to be hosted under the
19 OpenBMC architecture (bitbake, d-bus, phosphor-dbus-interfaces, ...).
22 guidelines to be used by the OpenBMC TOF in their decision to approve or not
25 Both hardware-specific and vendor-specific repositories should meet the
26 following requirements to be eligible for a repository under OpenBMC:
34 5. It is a feature that is believed to be generally useful to the OpenBMC
36    - Determination made by the TOF
37    - Reference: "Create a new repository" TOF [process][tof]
38 6. It has an active OpenBMC community member that is willing to be a maintainer
40 Note that the first option should always be to look into hosting the repository
41 under OpenBMC (vs. a recipe in OpenBMC that points to an external repository).
45 1. The repository depends on other OpenBMC-hosted repositories
47 If someone wishes to create a recipe within OpenBMC to point to an external
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
60 3. The maintainer of the repository must commit to quick turnaround on critical
63 Note that when a recipe is non-OpenBMC specific, but useful to OpenBMC, it
64 should be pushed upstream into meta-openembedded.
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
75 To add a hardware specific repository to OpenBMC, it should meet the following
82 example a CPLD code base that's only relevant to a particular vendors system,
83 may be better suited to be hosted externally to OpenBMC.
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
102 As OpenBMC has grown, so has the need for software function that is tied to
103 specific hardware families. For example, [OpenPOWER][openpower] was one of the
105 organization will show many repositories with that name in it. You will get a
108 OpenBMC in general is to be agnostic of the hardware it is managing, but that is
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.
120 The goal of this document is to clearly state the requirements and expectations
122 organization. This document aims to answer the following questions:
128    if a bitbake recipe can be added to OpenBMC to point to a vendors repository
135 OpenBMC wants to enable as many machines as possible with as many common paths
141 - A Hardware specific feature (implementation for a driver, support for
143 - Support for a vendor-specific feature. (OEM extensions, debug APIs, Redfish,
150 The OpenBMC project has a fairly extensive CI process, it has many great code
152 ensure a solid code base for others to use, and sets a certain standard for
158 repositories utilized by OpenBMC. It is always going to be easier to coordinate
160 to coordinate with externally hosted repositories.)
162 OpenBMC already hosts 100+ repositories, which can be very daunting to someone
165 project efforts. Having a set of guidelines for this process helps to speed up
166 new code development within the project. How useful is the feature, how many
169 we need to articulate into a vetting process.
171 In a perfect world, only hardware-specific features would be in the meta machine
177 This document was written to be a reference for people looking where to put
178 vendor specific features and also as a reference for the TOF team to review when
182 [upstream]: https://github.com/openbmc/docs/blob/master/kernel-development.md
183 [tof]: https://github.com/openbmc/technical-oversight-forum/issues