Mercurial > hg > kdocs
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>