]> Gitweb @ Texas Instruments - Open Source Git Repositories - git.TI.com/gitweb - android-sdk/platform-bionic.git/blobdiff - HACKING.txt
am 6cdab387: Merge "Restore <nsswitch.h> which is BSD API, not private."
[android-sdk/platform-bionic.git] / HACKING.txt
index 5785b3072b67c17cc214a5cafc54d62441169a75..fb93b5a105c8af162de48f6a9a7825f3f9aecea6 100644 (file)
@@ -81,19 +81,15 @@ libc/
   private/
     # These are private header files meant for use within bionic itself.
 
-  netbsd/
   stdio/
   stdlib/
-  string/
   unistd/
-  wchar/
     # These are legacy files of unknown provenance. In the past, bionic was a
     # mess of random versions of random files from all three of FreeBSD, NetBSD,
     # and OpenBSD! We've been working to clean that up, but these directories
     # are basically where all the stuff we haven't got to yet lives.
-    # The 'netbsd' directory misleadingly contains the DNS resolver (which will
-    # probably be forked sometime soon, and that directory simply renamed).
-    # The other directories contain stuff that still needs to be sorted.
+  dns/
+    # Contains the DNS resolver (originates from NetBSD code).
 
   upstream-dlmalloc/
   upstream-freebsd/
@@ -101,8 +97,14 @@ libc/
   upstream-openbsd/
     # These directories contain unmolested upstream source. Any time we can
     # just use a BSD implementation of something unmodified, we should.
-    # See files like netbsd-compat.h for various ways in which we manage to
-    # build BSD source in bionic.
+    # The structure under these directories mimics the upstream tree,
+    # but there's also...
+    android/
+      include/
+        # This is where we keep the hacks necessary to build BSD source
+        # in our world. The *-compat.h files are automatically included
+        # using -include, but we also provide equivalents for missing
+        # header/source files needed by the BSD implementation.
 
   bionic/
     # This is the biggest mess. The C++ files are files we own, typically
@@ -135,7 +137,7 @@ Adding a system call usually involves:
   3. Add constants (and perhaps types) to the appropriate header file.
      Note that you should check to see whether the constants are already in
      kernel uapi header files, in which case you just need to make sure that
-     that appropriate POSIX header file in libc/include/ includes the
+     the appropriate POSIX header file in libc/include/ includes the
      relevant file or files.
   4. Add function declarations to the appropriate header file.
   5. Add at least basic tests. Even a test that deliberately supplies