]> git.saurik.com Git - apple/xnu.git/blobdiff - README
xnu-3247.1.106.tar.gz
[apple/xnu.git] / README
diff --git a/README b/README
index 0d4d3285aaf29d869325eae54cce7882af6c5307..1294b6726f2fb316d8d94feb175bc84677d4ad3e 100644 (file)
--- a/README
+++ b/README
-How to build XNU:
+Table of contents:
+A. How to build XNU
+B. How to install a new header file from XNU
+
+=============================================
+A. How to build XNU:
 
 1) Type: "make"
 
 
 1) Type: "make"
 
-  This builds all the components for all architectures defined in 
-  ARCH_CONFIGS and for all kernel configurations defined in KERNEL_CONFIGS.
-  By default, ARCH_CONFIGS contains one architecture, the build machine 
-  architecture, and KERNEL_CONFIGS is set to build for RELEASE.
+  This builds all the components for kernel, architecture, and machine
+  configurations defined in TARGET_CONFIGS.  Additionally, we also support
+  architectures defined in ARCH_CONFIGS and kernel configurations defined in 
+  KERNEL_CONFIGS.  Note that TARGET_CONFIGS overrides any configurations defined
+  in ARCH_CONFIGS and KERNEL_CONFIGS.
+
+  By default, architecture defaults to the build machine 
+  architecture, and the kernel configuration is set to build for DEVELOPMENT.
+  
   This will also create a bootable image, mach_kernel,  and a kernel binary 
   with symbols, mach_kernel.sys.
 
   This will also create a bootable image, mach_kernel,  and a kernel binary 
   with symbols, mach_kernel.sys.
 
-  Example:
-    $(OBJROOT)/RELEASE_PPC/osfmk/RELEASE/osfmk.o: pre-linked object for osfmk component
-    $(OBJROOT)/RELEASE_PPC/mach_kernel: bootable image
 
 
-2) Building a Component
+       /* this is all you need to do to build with RELEASE kernel configuration  */
+       make TARGET_CONFIGS="release x86_64 default" SDKROOT=/path/to/SDK
+       
+       or the following is equivalent (ommitted SDKROOT will use /)
+       
+       make ARCH_CONFIGS=X86_64
 
 
-  Go to the top directory in your XNU project.
+2) Building DEBUG
 
 
-  If you are using a sh-style shell, run the following command:
-     $ . SETUP/setup.sh
+  Define kernel configuration to DEBUG in your environment or when running a 
+  make command.  Then, apply procedures 4, 5
 
 
-  If you are using a csh-style shell, run the following command:
-     % source SETUP/setup.csh
+  $ make TARGET_CONFIGS="DEBUG X86_64 DEFAULT" all
 
 
-  This will define the following environmental variables:
-    SRCROOT, OBJROOT, DSTROOT, SYMROOT
+  or
 
 
-  From a component top directory:
+  $ make KERNEL_CONFIGS=DEBUG ARCH_CONFIGS=X86_64 all
 
 
-    $ make all
+  or
 
 
-  This builds a component for all architectures defined in ARCH_CONFIGS 
-  and for all kernel configurations defined in KERNEL_CONFIGS. 
-  By default, ARCH_CONFIGS contains one architecture, the build machine 
-  architecture, and KERNEL_CONFIGS is set to build for RELEASE .
+  $ export TARGET_CONFIGS="DEBUG X86_64 DEFAULT"
+  $ export SDKROOT=/path/to/SDK
+  $ make all
 
   Example:
 
   Example:
-    $(OBJROOT)/RELEASE_PPC/osfmk/RELEASE/osfmk.o: pre-linked object for osfmk component
+    $(OBJROOT)/DEBUG_X86_64/osfmk/DEBUG/osfmk.filelist: list of objects in osfmk component
+    $(OBJROOT)/DEBUG_X86_64/mach_kernel: bootable image
 
 
-  From the component top directory:
+3) Building fat
 
 
-    $ make mach_kernel
+  Define architectures in your environment or when running a make command.
+  Apply procedures 3, 4, 5
 
 
-  This includes your component in the bootable image, mach_kernel,  and 
-  in the kernel binary with symbols, mach_kernel.sys.
+  $ make TARGET_CONFIGS="RELEASE I386 DEFAULT RELEASE X86_64 DEFAULT" exporthdrs all
 
 
-  WARNING: If a component header file has been modified, you will have to do 
-           the above procedure 1.
+  or
 
 
-3) Building DEBUG
+  $ make ARCH_CONFIGS="I386 X86_64" exporthdrs all
 
 
-  Define KERNEL_CONFIGS to DEBUG in your environment or when running a 
-  make command.  Then, apply procedures 4, 5
+  or
 
 
-  $ make KERNEL_CONFIGS=DEBUG all
+  $ export ARCH_CONFIGS="I386 X86_64"
+  $ make exporthdrs all
 
 
-  or
+4) Verbose make 
+   To display complete tool invocations rather than an abbreviated version,
+   $ make VERBOSE=YES
 
 
-  $ export KERNEL_CONFIGS=DEBUG
-  $ make all
+5) Debug information formats
+   By default, a DWARF debug information repository is created during the install phase; this is a "bundle" named mach_kernel.dSYM
+   To select the older STABS debug information format (where debug information is embedded in the mach_kernel.sys image), set the BUILD_STABS environment variable.
+   $ export BUILD_STABS=1
+   $ make
 
 
-  Example:
-    $(OBJROOT)/DEBUG_PPC/osfmk/DEBUG/osfmk.o: pre-linked object for osfmk component
-    $(OBJROOT)/DEBUG_PPC/mach_kernel: bootable image
+6) Build check before integration
 
 
-4) Building fat
+  From the top directory, run:
 
 
-  Define ARCH_CONFIGS in your environment or when running a make command.
-  Apply procedures 3, 4, 5
+    $ ~rc/bin/buildit . -arch i386 -arch x86_64 -arch armv7 -arch ppc -noinstallsrc -nosum
 
 
-  $ make ARCH_CONFIGS="PPC I386" exporthdrs all
+       
+  xnu supports a number of XBS build aliases, which allow B&I to build
+  the same source submission multiple times in different ways, to
+  produce different results. Each build alias supports the standard
+  "clean", "install", "installsrc", "installhdrs" targets, but
+  conditionalize their behavior on the RC_ProjectName make variable
+  which is passed as the -buildAlias argument to ~rc/bin/buildit, which
+  can be one of:
 
 
-  or
+  -buildAlias xnu            # the default, builds /mach_kernel, kernel-space
+                             # headers, user-space headers, man pages,
+                             # symbol-set kexts
 
 
-  $ export ARCH_CONFIGS="PPC I386"
-  $ make exporthdrs all
+  -buildAlias xnu_debug      # a DEBUG kernel in /AppleInternal with dSYM
 
 
-5) Build check before integration
+  -buildAlias libkxld        # user-space version of kernel linker
 
 
-  From the top directory, run:
+  -buildAlias libkmod        # static library automatically linked into kexts
+
+  -buildAlias Libsyscall     # automatically generate BSD syscall stubs
 
 
-    $ ~rc/bin/buildit . -arch ppc -arch i386 -noinstallsrc -nosum
+  -buildAlias xnu_quick_test # install xnu unit tests
 
 
-6) Creating tags and cscope
+
+
+7) Creating tags and cscope
 
   Set up your build environment as per instructions in 2a
 
   From the top directory, run:
 
 
   Set up your build environment as per instructions in 2a
 
   From the top directory, run:
 
-    $ make tags                # this will build ctags and etags
+    $ make tags                # this will build ctags and etags on a case-sensitive
+                       # volume, only ctags on case-insensitive
+
+    $ make TAGS                # this will build etags
 
     $ make cscope      # this will build cscope database
 
 
     $ make cscope      # this will build cscope database
 
+8) Reindenting files
+
+  Source files can be reindented using clang-format setup in .clang-format. XNU follow a variant of WebKit style for source code formatting. Please refer to format styles at http://www.webkit.org/coding/coding-style.html. Further options about style options is available at http://clang.llvm.org/docs/ClangFormatStyleOptions.html
+
+  Note: clang-format binary may not be part of base installation. It can be compiled from llvm clang sources and is reachable in $PATH.
+
+  From the top directory, run:
+
+   $ make reindent      # reindent all source files using clang format.
+
+
+9) Other makefile options
+
+   $ make MAKEJOBS=-j8    # this will use 8 processes during the build. The default is 2x the number of active CPUS.
+   $ make -j8             # the standard command-line option is also accepted
+
+   $ make -w              # trace recursive make invocations. Useful in combination with VERBOSE=YES
+
+   $ make BUILD_LTO=0    # build without LLVM Link Time Optimization
+
+   $ make REMOTEBUILD=user@remotehost # perform build on remote host
+
+   $ make BUILD_JSON_COMPILATION_DATABASE=1 # Build Clang JSON Compilation Database
+
+=============================================
+B. How to install a new header file from XNU
+
+[To install IOKit headers, see additional comments in iokit/IOKit/Makefile.]
+
+1) XNU installs header files at the following locations -
+       a. $(DSTROOT)/System/Library/Frameworks/Kernel.framework/Headers
+       b. $(DSTROOT)/System/Library/Frameworks/Kernel.framework/PrivateHeaders
+       c. $(DSTROOT)/usr/include/
+       d. $(DSTROOT)/System/Library/Frameworks/System.framework/PrivateHeaders
+
+       Kernel.framework is used by kernel extensions.  System.framework 
+       and /usr/include are used by user level applications.  The header 
+       files in framework's "PrivateHeaders" are only available for Apple 
+       Internal development.
+
+2) The directory containing the header file should have a Makefile that 
+   creates the list of files that should be installed at different locations.
+   If you are adding first header file in a directory, you will need to 
+   create Makefile similar to xnu/bsd/sys/Makefile.
+
+   Add your header file to the correct file list depending on where you want 
+   to install it.   The default locations where the header files are installed 
+   from each file list are -
+
+   a. DATAFILES : To make header file available in user level -
+         $(DSTROOT)/usr/include
+
+   b. PRIVATE_DATAFILES : To make header file available to Apple internal in 
+      user level -
+         $(DSTROOT)/System/Library/Frameworks/System.framework/PrivateHeaders
+
+   c. KERNELFILES : To make header file available in kernel level - 
+         $(DSTROOT)/System/Library/Frameworks/Kernel.framework/Headers
+         $(DSTROOT)/System/Library/Frameworks/Kernel.framework/PrivateHeaders
+
+   d. PRIVATE_KERNELFILES : To make header file available to Apple internal 
+      for kernel extensions - 
+         $(DSTROOT)/System/Library/Frameworks/Kernel.framework/PrivateHeaders
+
+3) The Makefile combines the file lists mentioned above into different 
+   install lists which are used by build system to install the header files.
+
+   If the install list that you are interested does not exist, create it
+   by adding the appropriate file lists.  The default install lists, its 
+   member file lists and their default location are described below - 
+
+   a. INSTALL_MI_LIST : Installs header file to a location that is available to
+      everyone in user level. 
+      Locations -
+         $(DSTROOT)/usr/include
+      Definition -
+         INSTALL_MI_LIST = ${DATAFILES}
+
+   b. INSTALL_MI_LCL_LIST : Installs header file to a location that is available
+      for Apple internal in user level.
+      Locations -
+         $(DSTROOT)/System/Library/Frameworks/System.framework/PrivateHeaders
+      Definition -
+         INSTALL_MI_LCL_LIST = ${PRIVATE_DATAFILES}
+
+   c. INSTALL_KF_MI_LIST : Installs header file to location that is available
+      to everyone for kernel extensions.
+      Locations -
+         $(DSTROOT)/System/Library/Frameworks/Kernel.framework/Headers
+      Definition -
+         INSTALL_KF_MI_LIST = ${KERNELFILES}
+
+   d. INSTALL_KF_MI_LCL_LIST : Installs header file to location that is 
+      available for Apple internal for kernel extensions.
+      Locations -
+         $(DSTROOT)/System/Library/Frameworks/Kernel.framework/PrivateHeaders
+      Definition -
+         INSTALL_KF_MI_LCL_LIST = ${KERNELFILES} ${PRIVATE_KERNELFILES}
+
+4) If you want to install the header file in a sub-directory of the paths 
+   described in (1), specify the directory name using two variable 
+   INSTALL_MI_DIR and EXPORT_MI_DIR as follows - 
+
+   INSTALL_MI_DIR = dirname
+   EXPORT_MI_DIR = dirname
+
+5) A single header file can exist at different locations using the steps 
+   mentioned above.  However it might not be desirable to make all the code
+   in the header file available at all the locations.  For example, you 
+   want to export a function only to kernel level but not user level.
+
+   You can use C language's pre-processor directive (#ifdef, #endif, #ifndef)
+   to control the text generated before a header file is installed.  The kernel 
+   only includes the code if the conditional macro is TRUE and strips out 
+   code for FALSE conditions from the header file.  
+
+   Some pre-defined macros and their descriptions are -
+   a. PRIVATE : If true, code is available to all of the xnu kernel and is 
+      not available in kernel extensions and user level header files.  The 
+      header files installed in all the paths described above in (1) will not 
+      have code enclosed within this macro.
+
+   b. KERNEL_PRIVATE : Same as PRIVATE
+
+   c. BSD_KERNEL_PRIVATE : If true, code is available to the xnu/bsd part of 
+      the kernel and is not available to rest of the kernel, kernel extensions 
+      and user level header files.  The header files installed in all the 
+      paths described above in (1) will not have code enclosed within this 
+      macro.
+
+   d. KERNEL :  If true, code is available only in kernel and kernel 
+      extensions and is not available in user level header files.  Only the 
+      header files installed in following paths will have the code - 
+         $(DSTROOT)/System/Library/Frameworks/Kernel.framework/Headers
+         $(DSTROOT)/System/Library/Frameworks/Kernel.framework/PrivateHeaders