docs/SystemLibrary.rst

   1 ==============
   2 System Library
   3 ==============
   4
   5 .. sectionauthor:: Reid Spencer <rspencer@x10sys.com>
   6
   7 Abstract
   8 ========
   9
  10
  11 This document provides some details on LLVM's System Library, located in the
  12 source at ``lib/System`` and ``include/llvm/System``. The library's purpose is
  13 to shield LLVM from the differences between operating systems for the few
  14 services LLVM needs from the operating system. Much of LLVM is written using
  15 portability features of standard C++. However, in a few areas, system dependent
  16 facilities are needed and the System Library is the wrapper around those system
  17 calls.
  18
  19 By centralizing LLVM's use of operating system interfaces, we make it possible
  20 for the LLVM tool chain and runtime libraries to be more easily ported to new
  21 platforms since (theoretically) only ``lib/System`` needs to be ported.  This
  22 library also unclutters the rest of LLVM from #ifdef use and special cases for
  23 specific operating systems. Such uses are replaced with simple calls to the
  24 interfaces provided in ``include/llvm/System``.
  25
  26 Note that the System Library is not intended to be a complete operating system
  27 wrapper (such as the Adaptive Communications Environment (ACE) or Apache
  28 Portable Runtime (APR)), but only provides the functionality necessary to
  29 support LLVM.
  30
  31 The System Library was written by Reid Spencer who formulated the design based
  32 on similar work originating from the eXtensible Programming System (XPS).
  33 Several people helped with the effort; especially, Jeff Cohen and Henrik Bach
  34 on the Win32 port.
  35
  36 Keeping LLVM Portable
  37 =====================
  38
  39 In order to keep LLVM portable, LLVM developers should adhere to a set of
  40 portability rules associated with the System Library. Adherence to these rules
  41 should help the System Library achieve its goal of shielding LLVM from the
  42 variations in operating system interfaces and doing so efficiently.  The
  43 following sections define the rules needed to fulfill this objective.
  44
  45 Don't Include System Headers
  46 ----------------------------
  47
  48 Except in ``lib/System``, no LLVM source code should directly ``#include`` a
  49 system header. Care has been taken to remove all such ``#includes`` from LLVM
  50 while ``lib/System`` was being developed.  Specifically this means that header
  51 files like "``unistd.h``", "``windows.h``", "``stdio.h``", and "``string.h``"
  52 are forbidden to be included by LLVM source code outside the implementation of
  53 ``lib/System``.
  54
  55 To obtain system-dependent functionality, existing interfaces to the system
  56 found in ``include/llvm/System`` should be used. If an appropriate interface is
  57 not available, it should be added to ``include/llvm/System`` and implemented in
  58 ``lib/System`` for all supported platforms.
  59
  60 Don't Expose System Headers
  61 ---------------------------
  62
  63 The System Library must shield LLVM from **all** system headers. To obtain
  64 system level functionality, LLVM source must ``#include "llvm/System/Thing.h"``
  65 and nothing else. This means that ``Thing.h`` cannot expose any system header
  66 files. This protects LLVM from accidentally using system specific functionality
  67 and only allows it via the ``lib/System`` interface.
  68
  69 Use Standard C Headers
  70 ----------------------
  71
  72 The **standard** C headers (the ones beginning with "c") are allowed to be
  73 exposed through the ``lib/System`` interface. These headers and the things they
  74 declare are considered to be platform agnostic. LLVM source files may include
  75 them directly or obtain their inclusion through ``lib/System`` interfaces.
  76
  77 Use Standard C++ Headers
  78 ------------------------
  79
  80 The **standard** C++ headers from the standard C++ library and standard
  81 template library may be exposed through the ``lib/System`` interface. These
  82 headers and the things they declare are considered to be platform agnostic.
  83 LLVM source files may include them or obtain their inclusion through
  84 ``lib/System`` interfaces.
  85
  86 High Level Interface
  87 --------------------
  88
  89 The entry points specified in the interface of ``lib/System`` must be aimed at
  90 completing some reasonably high level task needed by LLVM. We do not want to
  91 simply wrap each operating system call. It would be preferable to wrap several
  92 operating system calls that are always used in conjunction with one another by
  93 LLVM.
  94
  95 For example, consider what is needed to execute a program, wait for it to
  96 complete, and return its result code. On Unix, this involves the following
  97 operating system calls: ``getenv``, ``fork``, ``execve``, and ``wait``. The
  98 correct thing for ``lib/System`` to provide is a function, say
  99 ``ExecuteProgramAndWait``, that implements the functionality completely.  what
 100 we don't want is wrappers for the operating system calls involved.
 101
 102 There must **not** be a one-to-one relationship between operating system
 103 calls and the System library's interface. Any such interface function will be
 104 suspicious.
 105
 106 No Unused Functionality
 107 -----------------------
 108
 109 There must be no functionality specified in the interface of ``lib/System``
 110 that isn't actually used by LLVM. We're not writing a general purpose operating
 111 system wrapper here, just enough to satisfy LLVM's needs. And, LLVM doesn't
 112 need much. This design goal aims to keep the ``lib/System`` interface small and
 113 understandable which should foster its actual use and adoption.
 114
 115 No Duplicate Implementations
 116 ----------------------------
 117
 118 The implementation of a function for a given platform must be written exactly
 119 once. This implies that it must be possible to apply a function's
 120 implementation to multiple operating systems if those operating systems can
 121 share the same implementation. This rule applies to the set of operating
 122 systems supported for a given class of operating system (e.g. Unix, Win32).
 123
 124 No Virtual Methods
 125 ------------------
 126
 127 The System Library interfaces can be called quite frequently by LLVM. In order
 128 to make those calls as efficient as possible, we discourage the use of virtual
 129 methods. There is no need to use inheritance for implementation differences, it
 130 just adds complexity. The ``#include`` mechanism works just fine.
 131
 132 No Exposed Functions
 133 --------------------
 134
 135 Any functions defined by system libraries (i.e. not defined by ``lib/System``)
 136 must not be exposed through the ``lib/System`` interface, even if the header
 137 file for that function is not exposed. This prevents inadvertent use of system
 138 specific functionality.
 139
 140 For example, the ``stat`` system call is notorious for having variations in the
 141 data it provides. ``lib/System`` must not declare ``stat`` nor allow it to be
 142 declared. Instead it should provide its own interface to discovering
 143 information about files and directories. Those interfaces may be implemented in
 144 terms of ``stat`` but that is strictly an implementation detail. The interface
 145 provided by the System Library must be implemented on all platforms (even those
 146 without ``stat``).
 147
 148 No Exposed Data
 149 ---------------
 150
 151 Any data defined by system libraries (i.e. not defined by ``lib/System``) must
 152 not be exposed through the ``lib/System`` interface, even if the header file
 153 for that function is not exposed. As with functions, this prevents inadvertent
 154 use of data that might not exist on all platforms.
 155
 156 Minimize Soft Errors
 157 --------------------
 158
 159 Operating system interfaces will generally provide error results for every
 160 little thing that could go wrong. In almost all cases, you can divide these
 161 error results into two groups: normal/good/soft and abnormal/bad/hard. That is,
 162 some of the errors are simply information like "file not found", "insufficient
 163 privileges", etc. while other errors are much harder like "out of space", "bad
 164 disk sector", or "system call interrupted". We'll call the first group "*soft*"
 165 errors and the second group "*hard*" errors.
 166
 167 ``lib/System`` must always attempt to minimize soft errors.  This is a design
 168 requirement because the minimization of soft errors can affect the granularity
 169 and the nature of the interface. In general, if you find that you're wanting to
 170 throw soft errors, you must review the granularity of the interface because it
 171 is likely you're trying to implement something that is too low level. The rule
 172 of thumb is to provide interface functions that **can't** fail, except when
 173 faced with hard errors.
 174
 175 For a trivial example, suppose we wanted to add an "``OpenFileForWriting``"
 176 function. For many operating systems, if the file doesn't exist, attempting to
 177 open the file will produce an error.  However, ``lib/System`` should not simply
 178 throw that error if it occurs because its a soft error. The problem is that the
 179 interface function, ``OpenFileForWriting`` is too low level. It should be
 180 ``OpenOrCreateFileForWriting``. In the case of the soft "doesn't exist" error,
 181 this function would just create it and then open it for writing.
 182
 183 This design principle needs to be maintained in ``lib/System`` because it
 184 avoids the propagation of soft error handling throughout the rest of LLVM.
 185 Hard errors will generally just cause a termination for an LLVM tool so don't
 186 be bashful about throwing them.
 187
 188 Rules of thumb:
 189
 190 #. Don't throw soft errors, only hard errors.
 191
 192 #. If you're tempted to throw a soft error, re-think the interface.
 193
 194 #. Handle internally the most common normal/good/soft error conditions
 195    so the rest of LLVM doesn't have to.
 196
 197 No throw Specifications
 198 -----------------------
 199
 200 None of the ``lib/System`` interface functions may be declared with C++
 201 ``throw()`` specifications on them. This requirement makes sure that the
 202 compiler does not insert additional exception handling code into the interface
 203 functions. This is a performance consideration: ``lib/System`` functions are at
 204 the bottom of many call chains and as such can be frequently called. We need
 205 them to be as efficient as possible.  However, no routines in the system
 206 library should actually throw exceptions.
 207
 208 Code Organization
 209 -----------------
 210
 211 Implementations of the System Library interface are separated by their general
 212 class of operating system. Currently only Unix and Win32 classes are defined
 213 but more could be added for other operating system classifications.  To
 214 distinguish which implementation to compile, the code in ``lib/System`` uses
 215 the ``LLVM_ON_UNIX`` and ``LLVM_ON_WIN32`` ``#defines`` provided via configure
 216 through the ``llvm/Config/config.h`` file. Each source file in ``lib/System``,
 217 after implementing the generic (operating system independent) functionality
 218 needs to include the correct implementation using a set of
 219 ``#if defined(LLVM_ON_XYZ)`` directives. For example, if we had
 220 ``lib/System/File.cpp``, we'd expect to see in that file:
 221
 222 .. code-block:: c++
 223
 224   #if defined(LLVM_ON_UNIX)
 225   #include "Unix/File.cpp"
 226   #endif
 227   #if defined(LLVM_ON_WIN32)
 228   #include "Win32/File.cpp"
 229   #endif
 230
 231 The implementation in ``lib/System/Unix/File.cpp`` should handle all Unix
 232 variants. The implementation in ``lib/System/Win32/File.cpp`` should handle all
 233 Win32 variants.  What this does is quickly differentiate the basic class of
 234 operating system that will provide the implementation. The specific details for
 235 a given platform must still be determined through the use of ``#ifdef``.
 236
 237 Consistent Semantics
 238 --------------------
 239
 240 The implementation of a ``lib/System`` interface can vary drastically between
 241 platforms. That's okay as long as the end result of the interface function is
 242 the same. For example, a function to create a directory is pretty straight
 243 forward on all operating system. System V IPC on the other hand isn't even
 244 supported on all platforms. Instead of "supporting" System V IPC,
 245 ``lib/System`` should provide an interface to the basic concept of
 246 inter-process communications. The implementations might use System V IPC if
 247 that was available or named pipes, or whatever gets the job done effectively
 248 for a given operating system.  In all cases, the interface and the
 249 implementation must be semantically consistent.
 250