summaryrefslogtreecommitdiff
path: root/CODING_STYLE
diff options
context:
space:
mode:
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>2016-07-25 15:08:29 -0400
committerGitHub <noreply@github.com>2016-07-25 15:08:29 -0400
commitf86f6f829c3fc9544983040ec9d15bbd7df718e3 (patch)
tree18cc510b3f76256d1c8b0f1351a4a6283aa364e8 /CODING_STYLE
parent82fda58bc3fbe21e0ff609e84d625a38e8f6cca3 (diff)
parent0b81133facb7576e983ec8427ffc3a4a8cc62846 (diff)
Merge pull request #3802 from poettering/id128-fixes
Id128 fixes and more
Diffstat (limited to 'CODING_STYLE')
-rw-r--r--CODING_STYLE23
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.