diff options
| author | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2016-07-25 15:08:29 -0400 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2016-07-25 15:08:29 -0400 |
| commit | f86f6f829c3fc9544983040ec9d15bbd7df718e3 (patch) | |
| tree | 18cc510b3f76256d1c8b0f1351a4a6283aa364e8 /CODING_STYLE | |
| parent | 82fda58bc3fbe21e0ff609e84d625a38e8f6cca3 (diff) | |
| parent | 0b81133facb7576e983ec8427ffc3a4a8cc62846 (diff) | |
Merge pull request #3802 from poettering/id128-fixes
Id128 fixes and more
Diffstat (limited to 'CODING_STYLE')
| -rw-r--r-- | CODING_STYLE | 23 |
1 files changed, 23 insertions, 0 deletions
diff --git a/CODING_STYLE b/CODING_STYLE index f31d76f8ce..43cf57a49f 100644 --- a/CODING_STYLE +++ b/CODING_STYLE @@ -406,3 +406,26 @@ shorts as their name would suggest, but on uint32_t and uint16_t. Also, "network byte order" is just a weird name for "big endian", hence we might want to call it "big endian" right-away. + +- You might wonder what kind of common code belongs in src/shared/ and what + belongs in src/util/. The split is like this: anything that uses public APIs + we expose (i.e. any of the sd-bus, sd-login, sd-id128, ... APIs) must be + located in src/shared/. All stuff that only uses external libraries from + other projects (such as glibc's APIs), or APIs from src/basic/ itself should + be placed in src/basic/. Conversely, src/libsystemd/ may only use symbols + from src/basic, but not from src/shared/. To summarize: + + src/basic/ → may be used by all code in the tree + → may not use any code outside of src/basic/ + + src/shared/ → may be used by all code in the tree, except for code in src/basic/ + → may not use any code outside of src/basic/, src/shared/, src/libsystemd/ + + src/libsystemd/ → may be used by all code in the tree, except for code in src/basic/ + → may not use any code outside of src/basic/, src/shared/, src/libsystemd/ + +- Our focus is on the GNU libc (glibc), not any other libcs. If other libcs are + incompatible with glibc it's on them. However, if there are equivalent POSIX + and Linux/GNU-specific APIs, we generally prefer the POSIX APIs. If there + aren't, we are happy to use GNU or Linux APIs, and expect non-GNU + implementations of libc to catch up with glibc. |