xref: /openbmc/libpldm/docs/checklists/changes.md (revision ac3802e0)
1# Checklist for making changes to `libpldm`
2
3## Philosophy and influences
4
5- [Good Practices in Library Design, Implementation, and Maintenance - Ulrich
6  Drepper][goodpractice]
7
8[goodpractice]: https://www.akkadia.org/drepper/goodpractice.pdf
9
10- [How Do I Make This Hard to Misuse? - Rusty Russell][rusty-api-scale-good]
11
12[rusty-api-scale-good]: https://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html
13
14- [What If I Don't Actually Like My Users? - Rusty Russell][rusty-api-scale-bad]
15
16[rusty-api-scale-bad]: https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html
17
18## References
19
20- [C17 draft standard][c17-draft-standard]
21
22[c17-draft-standard]:
23  https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf
24
25## Definitions
26
27- **Error condition**: An invalid state reached at runtime, caused either by
28  resource exhaustion, or incorrect use of the library's public APIs and data
29  types.
30
31- **Invariant**: A condition in the library's implementation that must never
32  evaluate false.
33
34- **Public API**: Any definitions and declarations under `include/libpldm`.
35
36## Elaborations
37
38- Resource exhaustion is always an error condition and never an invariant
39  violation.
40
41- An invariant violation is always a programming failure of the library's
42  implementation, and never the result of incorrect use of the library's public
43  APIs (see error condition).
44
45- Corrollaries of the above two points:
46
47  - Incorrect use of public API functions is always an error condition, and is
48    dealt with by returning an error code.
49
50  - Incorrect use of static functions in the library's implementation is an
51    invariant violation which may be established using `assert()`.
52
53- `assert()` is the recommended way to demonstrate invariants are upheld.
54
55## Adding a new API
56
57- [ ] My new public `struct` definitions are _not_ marked
58      `__attribute__((packed))`
59
60- [ ] If my work interacts with the PLDM wire format, then I have done so using
61      the `msgbuf` APIs found in `src/msgbuf.h` (and under `src/msgbuf/`) to
62      minimise concerns around spatial memory safety and endian-correctness.
63
64- [ ] All my error conditions are handled by returning an error code to the
65      caller.
66
67- [ ] All my invariants are tested using `assert()`.
68
69- [ ] I have not used `assert()` to evaluate any error conditions without also
70      handling the error condition by returning an error code the the caller.
71
72  - Release builds of the library are configured with `assert()` disabled
73    (`-Db_ndebug=if-release`, which provides `-DNDEBUG` in `CFLAGS`).
74
75- [ ] If I've implemented a new function, then it returns a negative `errno`
76      value on error and not a PLDM completion code.
77
78  - [ ] The specific error values my function returns and their meaning in the
79        context of the function call are listed in the API documentation.
80
81- [ ] If I've added support for a new PLDM message type, then I've implemented
82      both the encoder and decoder for that message. Note this applies for both
83      request _and_ response message types.
84
85- [ ] My new function symbols are marked with `LIBPLDM_ABI_TESTING` in the
86      implementation
87
88- [ ] I've implemented test cases with reasonable branch coverage of each new
89      function I've added
90
91- [ ] I've guarded the test cases of functions marked `LIBPLDM_ABI_TESTING` so
92      that they are not compiled when the corresponding function symbols aren't
93      visible
94
95- [ ] If I've added support for a new message type, then my commit message
96      specifies all of:
97
98  - [ ] The relevant DMTF specification by its DSP number and title
99  - [ ] The relevant version of the specification
100  - [ ] The section of the specification that defines the message type
101
102- [ ] If my work impacts the public API of the library, then I've added an entry
103      to `CHANGELOG.md` describing my work
104
105## Stabilising an existing API
106
107- [ ] The API of interest is currently marked `LIBPLDM_ABI_TESTING`
108
109- [ ] My commit message links to a publicly visible patch that makes use of the
110      API
111
112- [ ] My commit updates the annotation from `LIBPLDM_ABI_TESTING` to
113      `LIBPLDM_ABI_STABLE` only for the function symbols demonstrated by the
114      patch linked in the commit message.
115
116- [ ] I've removed guards from the function's tests so they are always compiled
117
118- [ ] If I've updated the ABI dump, then I've used the OpenBMC CI container to
119      do so.
120
121## Updating an ABI dump
122
123Each of the following must succeed:
124
125- [ ] Enter the OpenBMC CI Docker container
126  - Approximately:
127    `docker run --cap-add=sys_admin --rm=true --privileged=true -u $USER -w $(pwd) -v $(pwd):$(pwd) -e MAKEFLAGS= -it openbmc/ubuntu-unit-test:2024-W21-ce361f95ff4fa669`
128- [ ] `CC=gcc CXX=g++; [ $(uname -m) = 'x86_64' ] && meson setup -Dabi=deprecated,stable build`
129- [ ] `meson compile -C build`
130- [ ] `./scripts/abi-dump-formatter < build/src/current.dump > abi/x86_64/gcc.dump`
131
132## Removing an API
133
134- [ ] If the function is marked `LIBPLDM_ABI_TESTING`, then I have removed it
135
136- [ ] If the function is marked `LIBPLDM_ABI_STABLE`, then I have changed the
137      annotation to `LIBPLDM_ABI_DEPRECATED` and left it in-place.
138
139- [ ] If the function is marked `LIBPLDM_ABI_DEPRECATED`, then I have removed it
140      only after satisfying myself that each of the following is true:
141
142  - [ ] There are no known users of the function left in the community
143  - [ ] There has been at least one tagged release of `libpldm` subsequent to
144        the API being marked deprecated
145
146## Testing my changes
147
148Each of the following must succeed when executed in order. Note that to avoid
149[googletest bug #4232][googletest-issue-4232] you must avoid using GCC 12
150(shipped in Debian Bookworm).
151
152[googletest-issue-4232]: https://github.com/google/googletest/issues/4232
153
154- [ ] `meson setup -Dabi-compliance-check=disabled build`
155- [ ] `meson compile -C build && meson test -C build`
156
157- [ ] `meson configure --buildtype=release build`
158- [ ] `meson compile -C build && meson test -C build`
159
160- [ ] `meson configure --buildtype=debug build`
161- [ ] `meson configure -Dabi=deprecated,stable build`
162- [ ] `meson compile -C build && meson test -C build`
163