From 0b81133facb7576e983ec8427ffc3a4a8cc62846 Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Mon, 25 Jul 2016 20:54:34 +0200 Subject: CODING_STYLE: document src/shared ←→ src/basic split MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- CODING_STYLE | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) 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. -- cgit v1.2.3-54-g00ecf