Mistake on this page?
Report an issue in GitHub or email us

Guidelines

License

This chapter covers the different aspects of developing your own libraries for use in Arm Mbed devices, as well as items to keep in mind during development, such as licensing. It covers:

Licensing binaries and libraries

When you write original code, you own the copyright and can choose to make it available to others under a license of your choice. A license gives rights and puts limitations on the reuse of your code by others. Not having a license means others cannot use your code. We encourage you to choose a license that makes possible (and encourages!) reuse by others.

If you create new software, such as drivers, libraries and examples, you can apply whatever license you like as the author and copyright holder of that code. Having said that, we encourage you to use a well-known license such as one of the ones listed on the SPDX License List, preferably an OSI-approved, permissive open source software license. Specifically, we recommend the following:

  • For original source code, use the Apache 2.0 license.  

  • For binary releases (for example, private source code you can’t or don’t want to release but want to share as a binary library and headers available for others to use), consider the Permissive Binary License. This is designed to be compatible with Apache 2.0 and the Mbed OS codebase.

  • If your software incorporates or is derived from other third party open source code, please be sure to retain all notices and identify the license for the third party licensed code in the same manner as described below. Remember, you cannot change the license on someone else’s code, because you are not the copyright holder! Instead, choose a license that is compatible with the license used by the third party open source code, or use the same license as that code. For example, if your software is derived from GPL source code, GPL requires you to license the rest of your code in that software under the GPL too. Note that many commercial users won’t be able to use GPL source code in their products, so we don't recommend this license if you're not obligated to use it.

You must either write all the code you provide yourself, or have the necessary rights to provide code written by someone else.

In all cases, whatever license you use, please use an SPDX license identifier in every source file following the recommendations to make it easier for users to understand and review licenses.

When to use Apache 2.0

Apache 2.0 is a permissive, free and open source software license that allows other parties to use, modify and redistribute the code in source and binary form. Compared to the often used BSD license, Apache 2.0 provides an express patent grant from contributors to users.

The full text of the license can be found on the Apache website. For more information about Apache 2.0, see the FAQ.

How to apply Apache 2.0 correctly

In order to clearly reflect the Apache 2.0 license, please create two text files:

  • A LICENSE file with the following text:
Unless specifically indicated otherwise in a file, files are licensed under the Apache 2.0 license,
as can be found in: LICENSE-apache-2.0.txt

Each source header should start with your copyright line, the SPDX identifier and the Apache 2.0 header as shown here:

Copyright (c) [First year]-[Last year], **Your Name or Company Here**
SPDX-License-Identifier: Apache-2.0

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.

You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
either express or implied.

See the License for the specific language governing permissions and limitations under the License.

When to use the Permissive Binary License

The Permissive Binary License (PBL) is a permissive license based on BSD-3-Clause and designed specifically for binary blobs. It's minimal but covers the basics, including an express patent grant.

It allows you to share a binary blob and the relevant headers, and allows others to use that binary blob as part of their product - as long as they provide it with all the relevant dependencies and don't modify it or reverse engineer it.

The full text can be found on mbed.com.

How to apply PBL correctly

In order to clearly reflect the PBL license, please create three text files:

  • A LICENSE file with:
Unless specifically indicated otherwise in a file, files are licensed under the Permissive Binary License,
as can be found in: LICENSE-permissive-binary-license-1.0.txt
  • The full original Permissive Binary License 1.0 text in LICENSE-permissive-binary-license-1.0.txt.

  • A DEPENDENCIES file with the dependencies that this binary requires to work properly. This is to make sure that third parties integrating the binary in their own distribution are aware that they need to include the relevant dependencies. If your binary does not have any dependencies, the file should state so (that is, say “No dependencies”); don't omit this file.

Each source header should start with your copyright line, the SPDX identifier and the PBL header:

Copyright (c) [First year]-[Last year], **Your Name Here**, All Rights Reserved
SPDX-License-Identifier: LicenseRef-PBL

This file and the related binary are licensed under the Permissive Binary License, Version 1.0 (the "License"); you may not use these files except in compliance with the License.

You may obtain a copy of the License here: LICENSE-permissive-binary-license-1.0.txt and at
https://www.mbed.com/licenses/PBL-1.0

See the License for the specific language governing permissions and limitations under the License.

Using a different license

If you decide to use a different license for your work, follow the same pattern:

  • Create a LICENSE file with a description of the license situation, following the pattern described in the sections above.

  • Put the full original license texts in separate documents named LICENSE-XYZ.txt, where XYZ is the corresponding SPDX identifier for your license.

  • Begin each source header with your copyright line, the SPDX identifier and the standard header for the license that applies to that single file, if it has one. (See SPDX Specification, Appendix V.)

  • If more than one license applies to the source file, then use an SPDX license expression (see SPDX Specification, Appendix IV), to reflect the presence of multiple licenses in your LICENSE file and in each source file.

Contributing to the Mbed OS codebase

Mbed OS principles

Mbed OS uses these same basic principles for its source code and library distributions. So source code we own is distributed under the Apache 2.0 license, and binary blobs are released under the Permissive Binary License. Software parts from third parties that were already licensed under a different license are available under that original license.

All the source code and binary blobs that end up in Mbed OS are maintained in public GitHub repositories.

CLA

If you want to contribute code to Mbed OS, you must sign an Mbed Contributor License Agreement (CLA). Please ask for a CLA before submitting any code (for example, while discussing the issue on GitHub), then wait for Arm to confirm acceptance of your CLA before making contributions.

Note: If you publish a feature or a solution to a problem before signing the CLA, then find out that you are not able or allowed to sign the CLA, we will not be able to use your solution anymore. That may prevent us from solving the problem for you.

When you ask for the CLA, we'll send you the agreement and ask you to sign it before we handle any pull request from you:

  • Individuals who want to contribute their own work must sign and return an Individual CLA.
  • Companies that want employees to contribute on its behalf must sign and return a Corporate CLA.

The same agreement is then valid for all future pull requests from that GitHub username.  

Style

The Arm Mbed OS codebase is hosted on GitHub, and you can submit new features or bug fixes. Please follow the guidelines for GitHub pull requests and the coding style guide in your submissions.

Tip: Please also read the CLA and workflow sections for a review of the process and legal requirements.

Code acceptance

After the CLA is in place and the code has gone through automated testing, developers will take a look and comment on the pull request. If all is well and acceptable, your code will be ready for merging into the central development branch.

Coding style

Whether you're writing new code or fixing bugs in existing code, please follow the Mbed OS coding style.

Mbed OS follows the K&R style, with at least two exceptions (which can be found in the list below the code sample).

Code sample
static const PinMap PinMap_ADC[] = {
    {PTC2, ADC0_SE4b, 0},
    {NC , NC , 0}
};

uint32_t adc_function(analogin_t *obj, uint32_t options)
{
    uint32_t instance = obj->adc >> ADC_INSTANCE_SHIFT;
    switch (options) {
        case 1:
            timeout = 6;
            break;
        default:
            timeout = 10;
            break;
    }

    while (!adc_hal_is_conversion_completed(instance, 0)) {
        if (timeout == 0) {
            break;
        } else {
            timeout--;
        }
    }

    if (obj->adc == ADC_CHANNEL0) {
        adc_measure_channel(instance);
        adc_stop_channel(instance);
    } else {
        error("channel not available");
    }

#if DEBUG
    for (uint32_t i = 0; i < 10; i++) {
        printf("Loop : %d", i);
    }
#endif
    return adc_hal_get_conversion_value(instance, 0);
}
Rules
  • Indentation - four spaces. Please do not use tabs.

  • Braces - K&R style.

  • One true brace style (1TBS) - use braces for statements of type if, else, while and for (exception from K&R).

  • One line per statement.

  • Preprocessor macro starts at the beginning of a new line; the code inside is indented according to the code above it.

  • Cases within switch are indented (exception from K&R).

  • Space after statements of type if, while, for, switch. The same applies to binary operators (like, + and *) and the ternary operator (? and :).

  • Each line preferably has at most 120 characters.

  • Comments should use proper spelling and grammar.

  • For pointers, * is adjacent to a name (analogin_t *obj).

  • Don't leave trailing spaces at the end of lines.

  • Empty lines should have no trailing spaces.

  • Unix line endings are default option for files.

  • Use capital letters for macros.

  • A file should have an empty line at the end.

Naming conventions
Classes
  • Begins with a capital letter, and each word in it also begins with a capital letter (AnalogIn, BusInOut).

  • Methods contain small letters, with words separated by underscore.

  • Private members starts with an underscore: __User defined types (typedef))).

  • Structures - suffix _t - to denote it is a user defined type.

  • Enumeration - the type name and values name - same naming convention as classes (for example MyNewEnum).

Functions
  • Contain lower case letters (as methods within classes).

  • Words separated by underscore (wait_ms, read_u16).

As an example:

#define ADC_INSTANCE_SHIFT 8


class AnalogIn {
public:
    /** Create an AnalogIn connected to the specified pin.
     *
     * @param pin AnalogIn pin to connect to
     * @param name (optional) A string to identify the object
     */
    AnalogIn(PinName pin)
    {
        analogin_init(&_adc, pin);
    }

    /** Read the input voltage, represented as a float in the range [0.0, 1.0].
     *
     * @returns
     * 	A floating-point value representing the current input voltage, measured as a percentage
     */
    uint32_t read()
    {
        return analogin_read(&_adc, operation);
    }
protected:
    analogin_t _adc;
};

typedef enum {
    ADC0_SE0 = (0 << ADC_INSTANCE_SHIFT) | 0,
} ADCName;

struct analogin_s {
    ADCName adc;
};

typedef struct analogin_s analogin_t;
Doxygen documentation

All functions and methods should contain documentation using Doxygen.

You can use Artistic Style (AStyle) to format your code. Use the command-line switch to select the correct style and point to the file you want to edit:

astyle.exe --style=kr --indent=spaces=4 --indents-switches $(full_path_to_file)

Compiler settings

All C and C++ code submitted to Mbed OS must compile with GCC Arm Embedded, Arm Compiler 5 and IAR EWARM. Mbed OS:

  • Uses the GNU99 standard for C.
  • Uses the GNU++98 standard for C++.
  • Sets the char type to unsigned.
  • Disables C++ exceptions.
  • Disables C++ runtime type information.
  • Disables variable length arrays (C++ only).

Software Design

Principles of Arm Mbed software:

  • Consistent.
  • Intuitive.
  • Simple.
  • Reliable.

Style

Please refer to the Mbed style guide.

Organization

The Arm Mbed OS codebase is organized into conceptual submodules to limit the scope and complexity of individual contributions. These modules are contained in the Mbed OS codebase as a single Git repo. We suggest this model for external libraries.

  • Modules should be logically grouped in the OS tree. Avoid generic words; be intentional with naming.

    - mbed-os
        |- rtos - user API + any layer required to fit into mbed OS
        |   |- rtx - third party implementation
        |   |- windows - third party implementation
        |   `- tests
        |       |- unit - rtos related unit tests
        |       `- functional - rtos related functional tests
        |- drivers - user API on-chip hardware interfaces (Ticker, DigitalOut, etc)
        |- util - chip-independent layer (retarget, toolchain, etc)
        |   `- bootloader - chip-independent bootloader
        |- net - networking API
        |   |- stack - network implementations  
        |   |   |-lwip
        |   |   `- nanostack
        |   `- tests - network tests
        `- tests
        |- integration - mbed OS integration tests
        `- smoke - mbed OS smoke tests (blinky, etc)
    
  • Prefix each source file with the module name followed by an underscore. This prevents conflicts with other similarly named files in different modules such as nanostack/thread.c and drivers/Thread.cpp; not all toolchains are able to support object files with the same name.

    mbed-os/rtos/rtos_thread.cpp
    mbed-os/rtos/rtos_semaphore.cpp
    mbed-os/drivers/drivers_analog_in.cpp
    
  • Always include header files using the module directory in the path. For example: #include “lwip/lwip-interface.h”, #include “drivers/Ticker.h”. Limit the include path to the module directory. This allows moving the module in the future.

  • As an entry point for the module (from the user space), we suggest a single header file. For example: mbed.h, rtos.h.

  • Header files should limit external includes to avoid indirectly exposing unrelated APIs. Header files should not expand namespaces.

  • In C++ modules, the API should be contained in a namespace that matches the module’s name. For example: mbed::Ticker, rtos::Thread, netsocket::Socket.

  • In C modules, every nonstatic function and type should be prefixed with the module’s name followed by an underscore. For example: mbed_critical_section_enter(), lwip_gethostbyname(host).

  • A module contained in the Mbed OS codebase may be mirrored in a separate repo. The source repo should be clearly identified and linked to from the module's README.

  • Special directories should follow consistent naming convention.

Contribution

  1. Please refer to the Mbed contribution guide.

  2. Each pull request should serve a single purpose.

  3. The code must compile every commit.

  4. Commit message should be prefixed with the submodule name and a colon:

    lwip: Fixed buffer overrun in rx loop
    The rx loop did not properly wait for rx semaphore to release
    causing the buffer to overrun
    
  5. Patches must land on master before being backported to one or more release branches.

  6. Feature development may happen in a separate branch, and brought to master when complete.

  7. The master branch and release branches must never be rewritten.

  8. All contributors must sign the CLA.

  9. For incoming sources, the only acceptable licenses are:

    • MIT.
    • Apache.
    • Permissive Binary License.

API design

A general module can be split into two APIs, the frontend (or user API) and the backend (or porting layer). The user API describes the programmer interface that the library implements. For Mbed OS, the user-facing API should adopt a C++ class-based interface, while the porting layer should adopt a C-compatible interface.

API design - user API
  • Each module should provide an object-oriented C++ user API.
  • The current standard is strictly C++03 (for portability).
  • State should be contained in relevant C++ classes.
  • Think twice before adopting language features that don't exist in the codebase:
    • Think C with the good parts of C++.
    • Don't make users learn new things.
    • Exceptions and RTTI are disabled.
    • Avoid the STL due to unknown effect on system resources.
  • Prefer C language features over C++ language features:
    • Use different function names over ambiguous overloads.
    • Do use uint8_t read_8(void), uint16_t read_16(void), uint32_t read_32(void).
    • Do use void write_8(uint8_t), void write_16(uint16_t), void write_32(uint32_t).
    • Limit templates to types and array-sizes.
  • Use pointers and references based on the following rules. Use appropriate documentation where ownership may be ambiguous:
    • Use a copy or immutable reference to pass types with value semantics.
    • Use a pointer to borrow ownership of dynamic polymorphic classes.
    • Use a pointer to transfer ownership of dynamic polymorphic classes. Clearly document transferred ownership.
    • Use pointers over references:
      • More familiar to C users.
    • Ownership is syntactically clear.
  • Organize classes into two types:
    • Types with value semantics such as SocketAddress and Callback.
    • User-friendly alternatives to builtin-types.
      • Cannot be extended (suffer from object slicing).
    • Pass by value, no memory management needed (handled on stack).
    • If possible, pass by const-reference to reduce copying.
    • Must be cheap to copy.
    • Should be small (<= 16 bytes). This does not include indirectly referenced memory.
    • Dynamic polymorphic classes such as Ticker and EthernetInterface:
      • Participate in class hierarchy.
      • Can be abstracted by interfaces.
      • Extendable - should have virtual table. Must contain virtual destructor if overloadable.
      • Passed by pointer; memory management should be left up to user.
      • Should declare copy constructor and copy assignment operator as private. If copying is really needed, we suggest a virtual clone member function, to avoid issues with slicing and indicate that the clone is a nontrivial operation.
      • If a class contains a very large memory region (> 64 bytes), prefer dynamically allocating the region; it prevents stack overflows if the user instantiates the class on the stack.
  • A class should have one responsibility. For example: UDPSocket vs TCPSocket, Ticker vs Timer.
  • Use inheritance for an “is a” relationship. For example: UDPSocket and Socket.
    • Prefer abstract base classes over template-based polymorphism to avoid code size increase.
    • Prefer composing abstract interfaces in C++ code over preprocessor-based conditional compilation and other forms of indirect dispatch.
  • Do not declare objects in global scope (applications should allocate global objects). Objects declared in global scope rarely get garbage-collected by compilers during link time. This can cause significant bloat in the size of an application.
  • Use get/set functions with private member variables to hide internal state from the user.
  • Avoid operations that can fail if you can't signal an error. Class constructors should not fail.
  • Nonrecoverable errors (such as OOM and mutex lock in interrupt) should not return to users.
  • Recoverable errors (such as UDP packet loss) should be propagated to the user via error code.
API design - porting layer
  • Each module should provide a C-compatible porting layer.
  • The current standards are strictly C99 (for portability).
  • The porting layer should make no assumptions about how it is consumed.
  • State should be contained in a struct passed by pointer from the user API. Avoid global state.
  • The porting layer should be designed to allow as much variance in the implementation as is reasonable.
  • Simplicity is beautiful.
Thread and IRQ safety
  • User APIs should be thread safe.
  • If a user API is intended to be interrupt safe, this should be clearly documented.
  • If a user API is unable to be thread safe, this should be clearly documented with warning notation. Use a consistent form across all APIs: "warning: not thread safe".
  • A module’s porting layer should be designed for implementations that are not thread safe.
  • If a callback is called in interrupt context, the API responsible should be clearly documented with a warning. Use a consistent form across all APIs: "warning: called from interrupt context"

Documentation

  • Each function and class in a module should provide a doxygen comment that documents the function and each argument and return value:

    /** Wait until a Mutex becomes available.
     *
     * @param   millisec  timeout value or 0 in case of no time-out. (default: osWaitForever)
     * @return  status code that indicates the execution status of the function.
     */
     osStatus lock(uint32_t millisec=osWaitForever);
    
  • The doxygen of each class's header file should contain a simple use example.

  • Each module should provide a README that documents the module:

    • The README should start with a small paragraph describing the module to users with no prior knowledge.
    • The README should contain a code example showing how to use the module.
    • If a module contains a porting layer, the README should include porting instructions.
    • If a module contains tests, the README should provide testing instruction.
  • Extended documentation should be located in the module’s docs directory with appropriate links from the module’s README.

Testing

  • Each module should contain a tests directory with tests that cover the module’s functionality.
  • Tests should be organized based on the class being tested; roughly one test file per class.
  • Tests included in the codebase must be compatible with the Mbed OS test framework.
  • To avoid regressions, every bug fix should include an additional test case that identifies the bug and deterministically fails before the bug is fixed.

Full documentation.

Configuration

Mbed OS provides a powerful configuration system for application development. However, modules should also be concerned with remaining configurable outside of the Mbed build system. Modules should provide well-documented configuration options in a simple header file.

  • Each module should provide a module_lib.json (or similar) with configuration options.
  • Each config option should contain documentation covering its purpose and effect on the system.
  • To help port new targets, each config option should provide a reasonable default (in case the config option is not defined).
  • Config options should not change the behavior of the API.
    • Prefer multiple classes where different functionality is needed in the user API.
  • Targets and applications should be able to override each configuration.
  • The default choice of optimization should be size, on all platforms.

Full documentation.

Workflow

Contributions

All code changes and additions to Mbed OS are handled through GitHub. If you want to contribute, either by adding features or by fixing bugs, please follow the guidelines for new features and bugs. In both cases, please follow the code style guide and GitHub pull request guidelines. Please also read the CLA guidelines because we will immediately close pull requests submitted without a CLA.

Contributing new features to Mbed OS

Before contributing an enhancement (new feature, new port and so on), please discuss it on the forums to avoid duplication of work, as we or others might be working on a related feature.

Patch contributions can only be accepted through GitHub by creating a pull request from forked versions of our repositories. This allows us to review the contributions in a user friendly and reliable way, under public scrutiny.

Please create separate pull requests for each concern; each pull request should have a clear unity of purpose. In particular, separate code formatting and style changes from functional changes. This makes each patch’s true contribution clearer and therefore quicker and easier to review.

Reporting and fixing bugs

Before submitting a bug report or a bug fix, please discuss it on the forums to avoid duplication of work, as we or others might be working on it already.

Bug reports (issues) on GitHub

All Mbed OS is on GitHub; please use GitHub's issues mechanism to open a bug report directly against the relevant GitHub repository.

Bug fixes

Please refer to the code contributions chapter.

A member of the Mbed team must verify bug fixes before we pull the fixes into the main branch. You must therefore use GitHub to fork the repo and then submit a pull request with your changes.

The last line in your commit message description should say “Fixes #deadbeef”, where “deadbeef” is the issue number in GitHub. This allows GitHub to automatically close the issue when the commit is merged into the default branch.

Further reading

Please see the code contributions chapter for the guidelines to GitHub pull requests and the coding style guide.

Guidelines for GitHub pull requests

Pull requests on GitHub have to meet the following requirements to keep the code and commit history clean:

  • Commits should always contain a proper description of their content. Start with a concise and sensible one-line description. Then, elaborate on reasoning of the choices made, descriptions for reviewers and other information that might otherwise be lost.
  • You should always write commits to allow publication, so they can never contain confidential information, reference private documents, links to intranet locations or rude language.
  • Each commit should be the minimum self-contained commit for a change. A commit should always result in a new state that is again in a compilable state. You should (if possible) split large changes into logical smaller commits that help reviewers follow the reasoning behind the full change.
  • Commits should follow Chris Beam’s seven rules of great commit messages:
    1. Separate subject from body with a blank line.
    2. Limit the subject line to 72 characters (note that this is a deviation from Beam's standard).
    3. Capitalize the subject line.
    4. Do not end the subject line with a period.
    5. Use the imperative mood in the subject line.
    6. Wrap the body at 72 characters.
    7. Use the body to explain what and why vs how.
  • Because we use GitHub and explicit CLAs, special commit tags that other projects may use, such as “Reviewed-by”, or “Signed-off-by”, are redundant and should be omitted. GitHub tracks who reviewed what and when, and our stack of signed CLAs shows us who has agreed to our development contribution agreement.
  • Prefixing your commit message with a domain is acceptable, and we recommend doing so when it makes sense. However, prefixing one's domain with the name of the repo is not useful. For example, making a commit entitled "mbed-drivers: Fix doppelwidget frobulation" to the mbed-drivers repo is not acceptable because it is already understood that the commit applies to mbed-drivers. Renaming the commit to "doppelwidget: Fix frobulation" would be better, if we presume that "doppelwidget" is a meaningful domain for changes, because it communicates that the change applies to the doppelwidget area of mbed-drivers.
  • All new features and enhancements require documentation, tests and user guides for us to accept them. Please link each pull request to all relevant documentation and testing pull requests.

Mbed OS maintainers

The maintainers are a small group of Mbed OS engineers who are responsible for the Mbed OS codebase. Their primary role is to progress contributions, both internal and external, from the initial pull request state through to released code. They:

  1. Check for CLA compliance.
  2. Ensure the relevant stakeholders review pull requests.
  3. Guide contributors both technically and procedurally.
  4. Run pull requests through the CI systems.
  5. Merge pull requests into the requested branches.
  6. Make periodic patch and feature releases.

The current maintainers are:

  • Anna Bridge (adbridge).
  • Martin Kojtal (0xc0170).
  • Jimmy Brisson (theotherjimmy).
  • Shrikant Tudavekar (studavekar).
  • Sam Grove (sg-).

GitHub pull requests workflow

Each pull request goes through the following workflow:

The workflow of merging a pull request

Pull request states

Labels that the Mbed OS maintainers add to a pull request represent the pull request workflow states. The Mbed OS maintainers are responsible for moving pull requests through the workflow states.

Reviews

All pull requests must be reviewed. The Mbed OS maintainers determine the most suitable person to review the pull request and tag that person accordingly. If a pull request requires a review from partners, the maintainers tag the corresponding GitHub group instead.

The CI (Continuous Integration) testing

There are a number of CI systems available. Which CI tests we run against a particular pull request depends on the effect of that pull request to the code base. Irrespective of which CIs tests run, Mbed OS has an all green policy, meaning that all the CI jobs that are triggered must pass before we merge the pull request.

Releases

Once we merge a pull request, we tag it with a release. This is the release in which we first publish this pull request. For patch releases, we allow only bug fixes, new targets and enhancements to existing functionality. New features only go to feature releases.

The release tag has the following format:

release-version: 5.f.p - Where f is the feature release and p the patch release.

Additional labels

We use many other labels to summarize the scope and effect of the changes.

  • needs: preceding PR - This pull request cannot yet be merged because it has a dependency on another pull request that needs to merge first.
  • DO NOT MERGE - This pull request contains changes that may be in a draft state and submitted purely for review, or may contain breaking changes that have not been considered.
  • devices: 'name' - The pull request specifically affects the named device(s).
  • component: 'name' - The pull request specifically affects the named component.

The following labels summarize the scope of the pull request.

  • scope: bug-fix.
  • scope: feature.
  • scope: new-target.
Important Information for this Arm website

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies. If you are not happy with the use of these cookies, please review our Cookie Policy to learn how they can be disabled. By disabling cookies, some features of the site will not work.