summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLennart Poettering <lennart@poettering.net>2016-07-25 20:54:34 +0200
committerLennart Poettering <lennart@poettering.net>2016-07-25 20:54:34 +0200
commit0b81133facb7576e983ec8427ffc3a4a8cc62846 (patch)
treea013d3b863d7d6988b5dbb7d3f9dad32acfcede8
parent65548c58dddf721d03d8a5f5c96b196510f158fb (diff)
CODING_STYLE: document src/shared ←→ src/basic split
Addresses: https://github.com/systemd/systemd/pull/3580#issuecomment-227931168 While we are at it, also document that we focus on glibc, not any other libcs.
-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.