changeset 61:3ea83bc83471

Add a little initial content under "Installing and using the kernel".
author Rob Landley <rob@landley.net>
date Tue, 02 Oct 2007 17:27:12 -0500
parents db0a5f758831
children eb75b1bfc3d1
files master.idx
diffstat 1 files changed, 89 insertions(+), 4 deletions(-) [+]
line wrap: on
line diff
--- a/master.idx	Tue Oct 02 14:01:29 2007 -0500
+++ b/master.idx	Tue Oct 02 17:27:12 2007 -0500
@@ -107,11 +107,96 @@
       <span id="initramfs, switch_root vs pivot_root, /dev/console">
       </span>
     </span>
-    <span id="init program and PID 1">
-      <span id="What does daemonizing really mean?">
+    <span id="Running programs">
+      <span id="init program and PID 1">
+        <span id="What does daemonizing really mean?">
+        </span>
+      </span>
+      <span id="Executable formats">
+<p>The Linux kernel runs programs in response to the
+<a href=xmlman/man3/exec.html>exec</a> syscall, which is called on a
+file.  This file must have the
+executable bit set, and must be on a filesystem that implements mmap() and which
+isn't mounted with the "noexec" option.  The kernel understands
+several different <a href="#executable_file_formats">executable file
+formats</a>, the most common of which are shell scripts and ELF binaries.</p>
+        <span id="Shell scripts">
+<p>If the first two bytes of an executable file are the characters "#!", the
+file is treated as a script file.  The kernel parses the first line of the file
+(until the first newline), and the first argument (immediately following
+the #! with no space) is used as absolute path to the script's interpreter,
+which must be an executable file.  Any additional arguments on the first
+line of the file (separated by whitespace) are passed as the first arguments
+to that interpreter executable.  The interpreter's next argument is the name of
+the script file, followed by the arguments given on the command line.</p>
+
+<p>To see this behavior in action, run the following:</p>
+<blockquote>
+<pre>echo "#!/bin/echo hello" > temp
+chmod +x temp
+./temp one two three
+</pre>
+</blockquote>
+
+<p>The result should be:</p>
+<blockquote>hello ./temp one two three</blockquote>
+
+<p>This is how shell scripts, perl, python, and other scripting languages
+work.  Even C code can be run as a script by installing the
+<a href=http://en.wikipedia.org/wiki/Tiny_C_Compiler>tinycc</a> package,
+adding "#!/usr/bin/tcc -run" to the start of the .c file, and setting the
+executable bit on the .c file.</p>
+        </span>
+        <span id="ELF">
+          <span id="Shared libraries">
+          </span>
+        </span>
       </span>
-    </span>
-    <span id="C library, Dynamic loader">
+
+      <span id="C library">
+<p>Most userspace programs access operating system functionality through a C
+library, usually installed at "/lib/libc.so.*".  The C library wraps system
+calls, and provides implementations of various standard functions.</p>
+
+<p>Because almost all other programming languages are implemented in C
+(including python, perl, php, java, javascript, ruby, flash, and just about
+everything else), programs written in other languages also make use of the
+C library to access operating system services.</p>
+
+<p>The most common C library implementations for Linux are
+<a href=http://www.linuxfromscratch.org/lfs/view/6.2/chapter06/glibc.html>glibc</a>
+and <a href=http://uClibc.org>uClibc</a>.  Both are full-featured
+implementations capable of supporting a full-featured desktop Linux
+distribution.</p>
+
+<p>The main advantage of glibc is that it's the standard implementation used by the
+largest desktop and server distributions, and has more features than any other
+implementation.  The main advantage of uClibc is that it's much smaller and
+simpler than glibc while still implementing almost all the same functionality.
+For comparison, a "hello world" program statically linked against glibc is half
+a megabyte when stripped, while the same program statically linked against
+uClibc strips down to 7k.</p>
+
+<p>Other commonly used special-purpose C library implementations include
+<a href=http://en.wikipedia.org/wiki/Klibc>klibc</a> and
+<a href=http://www.sourceware.org/newlib/>newlib</a>.</p>
+
+<span id="Exporting kernel headers">
+<p>Building a C library from source code requires a special set
+of Linux kernel header files, which describe the API of the specific version
+of the Linux kernel the C library will interface with.  However, the header
+files in the kernel source code are designed to build the kernel and contain
+a lot of internal information that would only confuse userspace.  These
+kernel headers must be "exported", filtering them for use by user space.</p>
+
+<p>Modern Linux kernels (based on 2.6.19.1 and newer) export kernel headers via
+the "make headers_install" command.  See
+<a href=local/headers_install.txt>exporting kernel headers for use by
+userspace</a> for more information.</p>
+</span>
+      </span>
+      <span id="Dynamic loader">
+      </span>
     </span>
     <span id="FHS directories">
       <p>FHS spec</p>