1# Optionality 2 3OpenBMC does its best to be widely applicable to all BMC deployments in the 4world, including many varieties of hardware. To do this requires care in the way 5new features are developed, to ensure stability of systems over time. With that 6as a goal, any given feature should fit into one of the following categories. 7 8## Core 9 10Required for the deployment of _any_ OpenBMC build. Examples of this include the 11Linux kernel, systemd, sdbusplus, and phosphor object mapper. These features are 12expected to remain widely applicable to all systems. 13 14## Subsystem 15 16These are subsystems that, while widely applicable, a user might choose to 17remove entire portions of the codebase that might not be needed in that 18deployment, or not used. This might be done to save binary size in the flash 19image, or might be done to reduce the security attack surface. These kids of 20features should be architected to ensure that, when removed, they do not cause 21functional impacts to other subsystems. Examples of these include the webui, 22Redfish, IPMI, and others. 23 24## Feature Configuration Types 25 26Features within an individual subsystem must be built such that they fall into 27one of these categories. For non-trivial feature additions, the commit message 28of the feature, as well as the design doc should explicitly state one of the 29following classes of feature. 30 31### Non configurable features 32 33Theses are features that are broadly applicable to all all deployments of a 34subsystem either by general usage, or by requirements in a specification, and 35therefore don't need to be able to be configured. Examples of these would 36include, Http keep alive, Security features like timeouts and payload size 37limits, and required commands. These types of features generally show no 38user-facing impact to function, although might do things like improve 39performance. 40 41Requires: Standards conformance, applicability to all flash-size systems, as 42well as all processor classes. 43 44### User opt-in features 45 46User opt-in features are features for which an external user must explicitly 47change their behavior to "opt in" to using a feature. Features like this, while 48they may be configurable at compile time, are not required to be configurable at 49compile time. Examples of this include Redfish query parameters, or IPMI OEM 50commands. 51 52Requires: Explicit, non-default user opt-in to execute the various features. 53 54### Developer opt-in features 55 56Many times a system or specific team might want a feature that is intended 57_only_ for a subset of the OpenBMC audience, and might add OEM parameters to 58non-standard interfaces, new command sets, or new APIs that might be applicable. 59Features of this nature MUST be configurable at either compile time or runtime, 60and generally will default to disabled. Features of this nature, when disabled, 61must take care to make no changes to the behavior of systems for which the 62feature is disabled. Company or feature specific functions, as well as the 63associated metadata must not be visible on a system for which the feature is 64disabled. Note, there are cases where _removing_ a feature might cause user 65impact, and therefore requires an option. 66 67CI will generally enable all developer opt-in features to ensure the most 68coverage of build configurations. 69 70Specific mechanisms to enable or disable these features are commonly: 71 721. Meson options 732. Entity-manager configuration 743. Yocto recipe changes 754. Phosphor ObjectMapper searches 76