]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/blob - contrib/arm-optimized-routines/README.contributors
libvmmapi: Move more amd64-specific ioctl wrappers to vmmapi_machdep.c
[FreeBSD/FreeBSD.git] / contrib / arm-optimized-routines / README.contributors
1 GENERIC CONTRIBUTION GUIDELINES
2 ===============================
3
4 1. Sub-projects are maintained independently and thus have independent
5    contribution rules. If there exists a README.contributors in the
6    sub-directory to which the contribution is made, it must be followed.
7
8 2. Legal:
9    - Contributors who are not employed by Arm must sign an Assignment Agreement.
10      See contributor-agreement.pdf.
11    - All code must be copyright owned by Arm Limited and the appropriate
12      copyright notice and license identifier must be present in every source
13      file.
14
15 3. Build:
16    - Build should only depend on GNU make and posix utilities (shell, awk, sed,
17      etc) and on a C toolchain.
18    - Build should pass with the default configuration (see config.mk.dist)
19      and other supported configurations, with both gcc and clang based
20      toolchains. (The build should not depend on a recent toolchain, the use
21      of a new feature should be possible to disable.)
22    - Currently there is no automated configuration, target specific configuration
23      should be done via make variables in config.mk. This is the user interface
24      to the build system, so it should be documented in sufficient detail and
25      kept reasonably stable.
26
27 4. Testing:
28    - On aarch64 the tests must pass. If the code may behave differently under
29      some supported configurations (e.g. CFLAGS) those should be tested.
30    - New symbols are expected to have new associated test code and ideally
31      benchmark code too.
32
33 4. Commits:
34    - Commit message should be descriptive and should not refer to Arm internal
35      information (such as Jira tickets, or internal discussions). Non-obvious
36      decisions should be recorded or explained in the commit message if they are
37      not explained in source comments.
38    - Ideally tools and scripts used to write the code should be added to the
39      repository or at least mentioned in the commit.
40    - Logically independent changes should not be mixed into the same commit.
41
42 5. Style:
43    - Unless otherwise required differently by the sub-project, follow the
44      clang-format tool using the style from the gcc contrib/ directory.