Mercurial > hg > kdocs
changeset 108:185c8f72730e
Bite the bullet and yank the old "attempt to write a kernel book" from the index page. Focus instead on the stuff that's actually there, so people can see it.
author | Rob Landley <rob@landley.net> |
---|---|
date | Sat, 19 Feb 2011 21:28:05 -0600 |
parents | dde34eaf03ed |
children | cfaf44286c4a |
files | index-old.html index.html |
diffstat | 2 files changed, 1508 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/index-old.html Sat Feb 19 21:28:05 2011 -0600 @@ -0,0 +1,1423 @@ +<html> +<title>Linux Kernel Documentation</title> +<body> + +<h2>Linux Kernel Documentation Index</h2> + +<p>This page collects and organizes documentation about the Linux kernel, taken +from many different sources. What is the kernel, how do you build it, how do +you use it, how do you change it...</p> + +<p>This is a work in progress, and probably always will be. Please let us know +on the +<a href=http://vger.kernel.org/vger-lists.html#linux-doc>linux-doc</a> mailing +list (on vger.kernel.org) about any documentation you'd like added to this +index, and feel free to ask about any topics that aren't covered here yet. +This index is maintained by Rob Landley <rob@landley.net>, and tracked in +<a href=http://landley.net/hg/kdocs>this mercurial repostiory</a>. The +cannonical location for the page is <a href=http://kernel.org/doc>here</a>.</p> + +<hr> + + <h2><a href="#Sources_of_documentation" name="1">1 Sources of documentation</a></h2> +<ul> + <li><a href="#From_the_kernel" name="1.1">1.1 From the kernel</a></li> + <li><a href="#Out_on_the_web" name="1.2">1.2 Out on the web</a></li> + <li><a href="#Standards" name="1.3">1.3 Standards</a></li> + <li><a href="#Translations" name="1.4">1.4 Translations</a></li> + </ul> + <h2><a href="#Building_from_source" name="2">2 Building from source</a></h2> +<ul> + <li><a href="#User_interface" name="2.1">2.1 User interface</a></li> + <ul> + <li><a href="#Get_and_extract_the_source" name="2.1.1">2.1.1 Get and extract the source</a></li> + <li><a href="#Configuring" name="2.1.2">2.1.2 Configuring</a></li> + <ul> + <li><a href="#Using_an_existing_configuration" name="2.1.2.1">2.1.2.1 Using an existing configuration</a></li> + <li><a href="#Creating_a_custom_kernel_configuration" name="2.1.2.2">2.1.2.2 Creating a custom kernel configuration</a></li> + </ul> + <li><a href="#building" name="2.1.3">2.1.3 building</a></li> + <ul> + <li><a href="#Building_out_of_tree" name="2.1.3.1">2.1.3.1 Building out of tree</a></li> + </ul> + <li><a href="#Installing" name="2.1.4">2.1.4 Installing</a></li> + <li><a href="#running" name="2.1.5">2.1.5 running</a></li> + <li><a href="#debugging" name="2.1.6">2.1.6 debugging</a></li> + <ul> + <li><a href="#QEMU" name="2.1.6.1">2.1.6.1 QEMU</a></li> + </ul> + <li><a href="#cross_compiling" name="2.1.7">2.1.7 cross compiling</a></li> + <ul> + <li><a href="#Cross_compiling_vs_native_compiling" name="2.1.7.1">2.1.7.1 Cross compiling vs native compiling</a></li> + <li><a href="#User_Mode_Linux" name="2.1.7.2">2.1.7.2 User Mode Linux</a></li> + </ul> + </ul> + <li><a href="#Infrastructure" name="2.2">2.2 Infrastructure</a></li> + <ul> + <li><a href="#kconfig" name="2.2.1">2.2.1 kconfig</a></li> + <li><a href="#kbuild" name="2.2.2">2.2.2 kbuild</a></li> + <li><a href="#build_and_link_(tmppiggy)" name="2.2.3">2.2.3 build and link (tmppiggy)</a></li> + </ul> + </ul> + <h2><a href="#Installing_and_using_the_kernel" name="3">3 Installing and using the kernel</a></h2> +<ul> + <li><a href="#Installing" name="3.1">3.1 Installing</a></li> + <ul> + <li><a href="#Kernel_image" name="3.1.1">3.1.1 Kernel image</a></li> + <li><a href="#Bootloader" name="3.1.2">3.1.2 Bootloader</a></li> + </ul> + <li><a href="#A_working_Linux_root_filesystem" name="3.2">3.2 A working Linux root filesystem</a></li> + <ul> + <li><a href="#Finding_and_mounting__" name="3.2.1">3.2.1 Finding and mounting /</a></li> + <ul> + <li><a href="#initramfs,_switch_root_vs_pivot_root,__dev_console" name="3.2.1.1">3.2.1.1 initramfs, switch_root vs pivot_root, /dev/console</a></li> + </ul> + <li><a href="#Running_programs" name="3.2.2">3.2.2 Running programs</a></li> + <ul> + <li><a href="#init_program_and_PID_1" name="3.2.2.1">3.2.2.1 init program and PID 1</a></li> + <ul> + <li><a href="#What_does_daemonizing_really_mean" name="3.2.2.1.1">3.2.2.1.1 What does daemonizing really mean?</a></li> + </ul> + <li><a href="#Executable_formats" name="3.2.2.2">3.2.2.2 Executable formats</a></li> + <ul> + <li><a href="#Shell_scripts" name="3.2.2.2.1">3.2.2.2.1 Shell scripts</a></li> + <li><a href="#ELF" name="3.2.2.2.2">3.2.2.2.2 ELF</a></li> + <ul> + <li><a href="#Shared_libraries" name="3.2.2.2.2.1">3.2.2.2.2.1 Shared libraries</a></li> + </ul> + </ul> + <li><a href="#C_library" name="3.2.2.3">3.2.2.3 C library</a></li> + <ul> + <li><a href="#Exporting_kernel_headers" name="3.2.2.3.1">3.2.2.3.1 Exporting kernel headers</a></li> + </ul> + <li><a href="#Dynamic_loader" name="3.2.2.4">3.2.2.4 Dynamic loader</a></li> + </ul> + <li><a href="#FHS_directories" name="3.2.3">3.2.3 FHS directories</a></li> + </ul> + </ul> + <h2><a href="#Reading_the_source_code" name="4">4 Reading the source code</a></h2> +<ul> + <li><a href="#Source_code_layout" name="4.1">4.1 Source code layout</a></li> + <ul> + <li><a href="#Following_the_boot_process" name="4.1.1">4.1.1 Following the boot process</a></li> + <li><a href="#Major_subsystems" name="4.1.2">4.1.2 Major subsystems</a></li> + <li><a href="#Architectures" name="4.1.3">4.1.3 Architectures</a></li> + </ul> + <li><a href="#Concept_vs_implementation" name="4.2">4.2 Concept vs implementation</a></li> + <li><a href="#Concepts" name="4.3">4.3 Concepts</a></li> + <ul> + <li><a href="#rbtree" name="4.3.1">4.3.1 rbtree</a></li> + <li><a href="#rcu" name="4.3.2">4.3.2 rcu</a></li> + </ul> + </ul> + <h2><a href="#Kernel_infrastructure" name="5">5 Kernel infrastructure</a></h2> +<ul> + <li><a href="#Process_Scheduler" name="5.1">5.1 Process Scheduler</a></li> + <ul> + <li><a href="#History_of_the_Linux_Process_Scheduler" name="5.1.1">5.1.1 History of the Linux Process Scheduler</a></li> + <li><a href="#fork,_exec" name="5.1.2">5.1.2 fork, exec</a></li> + <li><a href="#sleep" name="5.1.3">5.1.3 sleep</a></li> + <li><a href="#realtime" name="5.1.4">5.1.4 realtime</a></li> + </ul> + <li><a href="#Timers" name="5.2">5.2 Timers</a></li> + <ul> + <li><a href="#Interrupt_handling" name="5.2.1">5.2.1 Interrupt handling</a></li> + </ul> + <li><a href="#memory_management" name="5.3">5.3 memory management</a></li> + <ul> + <li><a href="#mmap,_DMA" name="5.3.1">5.3.1 mmap, DMA</a></li> + </ul> + <li><a href="#vfs" name="5.4">5.4 vfs</a></li> + <ul> + <li><a href="#Pipes,_files,_and_ttys" name="5.4.1">5.4.1 Pipes, files, and ttys</a></li> + <li><a href="#Filesystems" name="5.4.2">5.4.2 Filesystems</a></li> + <ul> + <li><a href="#Types_of_filesystems_(see__proc_filesystems)" name="5.4.2.1">5.4.2.1 Types of filesystems (see /proc/filesystems)</a></li> + <ul> + <li><a href="#Block_backed" name="5.4.2.1.1">5.4.2.1.1 Block backed</a></li> + <ul> + <li><a href="#ext2" name="5.4.2.1.1.1">5.4.2.1.1.1 ext2</a></li> + <li><a href="#jffs2" name="5.4.2.1.1.2">5.4.2.1.1.2 jffs2</a></li> + <li><a href="#vxfs" name="5.4.2.1.1.3">5.4.2.1.1.3 vxfs</a></li> + </ul> + <li><a href="#Ram_backed" name="5.4.2.1.2">5.4.2.1.2 Ram backed</a></li> + <ul> + <li><a href="#ramfs" name="5.4.2.1.2.1">5.4.2.1.2.1 ramfs</a></li> + <li><a href="#tmpfs" name="5.4.2.1.2.2">5.4.2.1.2.2 tmpfs</a></li> + </ul> + <li><a href="#Synthetic" name="5.4.2.1.3">5.4.2.1.3 Synthetic</a></li> + <ul> + <li><a href="#proc" name="5.4.2.1.3.1">5.4.2.1.3.1 proc</a></li> + <li><a href="#sys" name="5.4.2.1.3.2">5.4.2.1.3.2 sys</a></li> + <li><a href="#internal_(pipefs)" name="5.4.2.1.3.3">5.4.2.1.3.3 internal (pipefs)</a></li> + <li><a href="#usbfs" name="5.4.2.1.3.4">5.4.2.1.3.4 usbfs</a></li> + <li><a href="#devpts" name="5.4.2.1.3.5">5.4.2.1.3.5 devpts</a></li> + <li><a href="#rootfs" name="5.4.2.1.3.6">5.4.2.1.3.6 rootfs</a></li> + <li><a href="#devfs_(obsolete)" name="5.4.2.1.3.7">5.4.2.1.3.7 devfs (obsolete)</a></li> + </ul> + <li><a href="#Network" name="5.4.2.1.4">5.4.2.1.4 Network</a></li> + <ul> + <li><a href="#nfs" name="5.4.2.1.4.1">5.4.2.1.4.1 nfs</a></li> + <li><a href="#smb_cifs" name="5.4.2.1.4.2">5.4.2.1.4.2 smb/cifs</a></li> + <li><a href="#FUSE" name="5.4.2.1.4.3">5.4.2.1.4.3 FUSE</a></li> + </ul> + </ul> + <li><a href="#Filesystem_drivers" name="5.4.2.2">5.4.2.2 Filesystem drivers</a></li> + <ul> + <li><a href="#Using" name="5.4.2.2.1">5.4.2.2.1 Using</a></li> + <li><a href="#Writing" name="5.4.2.2.2">5.4.2.2.2 Writing</a></li> + </ul> + </ul> + </ul> + <li><a href="#Drivers" name="5.5">5.5 Drivers</a></li> + <ul> + <li><a href="#Filesystem" name="5.5.1">5.5.1 Filesystem</a></li> + <li><a href="#Block_(block_layer,_scsi_layer)" name="5.5.2">5.5.2 Block (block layer, scsi layer)</a></li> + <ul> + <li><a href="#SCSI_layer" name="5.5.2.1">5.5.2.1 SCSI layer</a></li> + </ul> + <li><a href="#Character" name="5.5.3">5.5.3 Character</a></li> + <ul> + <li><a href="#serial" name="5.5.3.1">5.5.3.1 serial</a></li> + <li><a href="#keyboard" name="5.5.3.2">5.5.3.2 keyboard</a></li> + <li><a href="#tty" name="5.5.3.3">5.5.3.3 tty</a></li> + <ul> + <li><a href="#pty" name="5.5.3.3.1">5.5.3.3.1 pty</a></li> + </ul> + <li><a href="#audio" name="5.5.3.4">5.5.3.4 audio</a></li> + <li><a href="#null" name="5.5.3.5">5.5.3.5 null</a></li> + <li><a href="#random_urandom" name="5.5.3.6">5.5.3.6 random/urandom</a></li> + <li><a href="#zero" name="5.5.3.7">5.5.3.7 zero</a></li> + </ul> + <li><a href="#DRI" name="5.5.4">5.5.4 DRI</a></li> + <li><a href="#Network" name="5.5.5">5.5.5 Network</a></li> + </ul> + <li><a href="#Hotplug" name="5.6">5.6 Hotplug</a></li> + <li><a href="#Input_core" name="5.7">5.7 Input core</a></li> + <li><a href="#Network" name="5.8">5.8 Network</a></li> + <li><a href="#Modules" name="5.9">5.9 Modules</a></li> + <ul> + <li><a href="#Exported_symbols" name="5.9.1">5.9.1 Exported symbols</a></li> + </ul> + <li><a href="#Busses" name="5.10">5.10 Busses</a></li> + <li><a href="#Security" name="5.11">5.11 Security</a></li> + <ul> + <li><a href="#Traditional_Unix_security_model" name="5.11.1">5.11.1 Traditional Unix security model</a></li> + <li><a href="#More_complicated_security_models" name="5.11.2">5.11.2 More complicated security models</a></li> + <ul> + <li><a href="#Posix_capabilities" name="5.11.2.1">5.11.2.1 Posix capabilities</a></li> + <li><a href="#SELinux" name="5.11.2.2">5.11.2.2 SELinux</a></li> + </ul> + <li><a href="#Encryption" name="5.11.3">5.11.3 Encryption</a></li> + </ul> + <li><a href="#API_(how_userspace_talks_to_the_kernel)" name="5.12">5.12 API (how userspace talks to the kernel)</a></li> + <ul> + <li><a href="#Syscalls" name="5.12.1">5.12.1 Syscalls</a></li> + <li><a href="#ioctls" name="5.12.2">5.12.2 ioctls</a></li> + <li><a href="#executable_file_formats" name="5.12.3">5.12.3 executable file formats</a></li> + <ul> + <li><a href="#a.out" name="5.12.3.1">5.12.3.1 a.out</a></li> + <li><a href="#elf" name="5.12.3.2">5.12.3.2 elf</a></li> + <ul> + <li><a href="#css,_bss,_etc." name="5.12.3.2.1">5.12.3.2.1 css, bss, etc.</a></li> + </ul> + <li><a href="#scripts" name="5.12.3.3">5.12.3.3 scripts</a></li> + <li><a href="#flat" name="5.12.3.4">5.12.3.4 flat</a></li> + <li><a href="#misc" name="5.12.3.5">5.12.3.5 misc</a></li> + </ul> + <li><a href="#Device_nodes" name="5.12.4">5.12.4 Device nodes</a></li> + <li><a href="#Pipes_(new_pipe_infrastructure)" name="5.12.5">5.12.5 Pipes (new pipe infrastructure)</a></li> + <li><a href="#Synthetic_filesystems_(as_API)" name="5.12.6">5.12.6 Synthetic filesystems (as API)</a></li> + </ul> + </ul> + <h2><a href="#Hardware" name="6">6 Hardware</a></h2> +<ul> + <li><a href="#Architectures" name="6.1">6.1 Architectures</a></li> + <ul> + <li><a href="#alpha" name="6.1.1">6.1.1 alpha</a></li> + <li><a href="#arm" name="6.1.2">6.1.2 arm</a></li> + <li><a href="#ia64" name="6.1.3">6.1.3 ia64</a></li> + <li><a href="#m68knommu" name="6.1.4">6.1.4 m68knommu</a></li> + <li><a href="#mips" name="6.1.5">6.1.5 mips</a></li> + <li><a href="#parisc" name="6.1.6">6.1.6 parisc</a></li> + <li><a href="#powerpc" name="6.1.7">6.1.7 powerpc</a></li> + <li><a href="#ppc" name="6.1.8">6.1.8 ppc</a></li> + <li><a href="#um" name="6.1.9">6.1.9 um</a></li> + <li><a href="#x86_64" name="6.1.10">6.1.10 x86_64</a></li> + </ul> + <li><a href="#DMA,_IRQ,_MMU_(mmap),_IOMMU,_port_I_O" name="6.2">6.2 DMA, IRQ, MMU (mmap), IOMMU, port I/O</a></li> + <li><a href="#Busses" name="6.3">6.3 Busses</a></li> + <ul> + <li><a href="#PCI,_USB" name="6.3.1">6.3.1 PCI, USB</a></li> + </ul> + </ul> + <h2><a href="#Following_Linux_development" name="7">7 Following Linux development</a></h2> +<ul> + <li><a href="#Distibutions" name="7.1">7.1 Distibutions</a></li> + <li><a href="#Releases" name="7.2">7.2 Releases</a></li> + <ul> + <li><a href="#Source_control" name="7.2.1">7.2.1 Source control</a></li> + </ul> + <li><a href="#community" name="7.3">7.3 community</a></li> + <li><a href="#Submitting_Patches" name="7.4">7.4 Submitting Patches</a></li> + </ul> + <h2><a href="#Glossary" name="8">8 Glossary</a></h2> +<hr> + +<h2><a href="#1" name="Sources_of_documentation">1 Sources of documentation</a></h2> +<span id="Sources of documentation"> + +<p>These are various upstream sources of documentation, many of which are linked +into the <a href=http://kernel.org/doc>linux kernel documentation index</a>.</p> + +<h2><a href="#1.1" name="From_the_kernel">1.1 From the kernel</a></h2> +<span id="From the kernel"> +<ul> +<li><a href=Documentation>Text files in the kernel's Documentation directory.</a></li> +<li><a href=htmldocs>Output of kernel's "make htmldocs".</a></li> +<li><a href=makehelp.txt>Output of kernel's "make help".</a></li> +<li><a href=menuconfig>Menuconfig/kconfig help for each configuration option.</a></li> +<li><a href=readme>Linux kernel README files</a></li> +<li><a href=rfc-linux.html>IETF RFCs referred to by kernel source files.</a></li> +</ul> +<h2><a href="#1.2" name="Out_on_the_web">1.2 Out on the web</a></h2> +<span id="Out on the web"> +<ul> +<li><a href=http://kernel.org/doc/man-pages>Linux man-pages website, includes HTML versions of man pages</a></li> +<li><a href=http://lwn.net/Kernel/Index/>Linux Weekly News kernel articles</a></li> +<li>Linux Device Drivers book (<a href=http://lwn.net/Kernel/LDD3/>third edition</a>) (<a href=http://www.xml.com/ldd/chapter/book/>second edition</a>)</li> +<li><a href=ols>Ottawa Linux Symposium papers</a></li> +<li><a href=als1999>Atlanta Linux Showcase CD (1999)</a></li> +<li><a href=http://www.linuxjournal.com/xstatic/magazine/archives>Linux Journal archives</a></li> +<li><a href=http://www.ibm.com/developerworks/views/linux/library.jsp>IBM Developerworks Linux Library</a> (also <a href=http://www.ibm.com/developerworks/linux/library/l-linux-kernel/>here</a>) +</li> +<li><a href=http://www.tux.org/lkml/>Linux Kernel Mailing List FAQ</a></li> +<li><a href=http://kernelplanet.org>Kernel Planet (blog aggregator)</a></li> +<li><a href=video.html>Selected videos of interest</a></li> +<li><a href=local>Some locally produced docs</a></li> +</ul> +<h2><a href="#1.3" name="Standards">1.3 Standards</a></h2> +<span id="Standards"> +<ul> +<li><a href=http://www.opengroup.org/onlinepubs/9699919799/>Single Unix Specification v4</a> (Also known as Open Group Base Specifications issue 7, and POSIX 2008. See especially <a href=http://www.opengroup.org/onlinepubs/9699919799/idx/xsh.html>system interfaces</a>)</li> +<li>C99 standard (defining the C programming language): <a href=http://www.open-std.org/jtc1/sc22/wg14/www/standards>ISO/IEC C9899 PDF</a>, <a href=http://busybox.net/~landley/c99-draft.html>html</a>, or <a href=http://c0x.coding-guidelines.com/>searchable website</a>.</li> +<li><a href=http://www.linux-foundation.org/spec/refspecs/>Linux Foundation's specs page</a> (ELF, Dwarf, ABI...)</li> +</ul> +<h2><a href="#1.4" name="Translations">1.4 Translations</a></h2> +<span id="Translations"> +<ul> +<li><a href=http://tlktp.sourceforge.net/>Linux Kernel Translation Project</a></li> +<li><a href=http://kernelnewbies.org/RegionalNewbies>Kernel Newbies regional pages</a></li> +<li><a href=http://www.linux.or.jp/JF/index.html>Japanese</a></li> +<li><a href=http://zh-kernel.org/docs>Chinese</a></li> +</ul> +<h2><a href="#2" name="Building_from_source">2 Building from source</a></h2> +<span id="Building from source"> + <h2><a href="#2.1" name="User_interface">2.1 User interface</a></h2> +<span id="User interface"> +<p>Building source packages is usually a three step process: configure, build, +and install.</p> + +<p>The Linux kernel is configured with the command "make menuconfig", built +with the command "make", and installed either manually or with the command +"make install".</p> + +<blockquote> +<pre> +tar xvjf linux-2.6.??.tar.bz2 +cd linux-2.6.?? +make menuconfig +make +make install +</pre> +</blockquote> + +<p>For a description of the make options and targets, type <a href=makehelp.txt> +make help</a>.</p> + +<h2><a href="#2.1.1" name="Get_and_extract_the_source">2.1.1 Get and extract the source</a></h2> +<span id="Get and extract the source"> +<p>The Linux kernel source code is distributed by +<a href=http://kernel.org>kernel.org</a> as tar archives. Grab the most recent +"stable" release (using the tiny little letter F link) to grab a file of the +form "linux-2.6.*.tar.bz2" from the +<a href=http://kernel.org/pub/linux/kernel/v2.6/>Linux 2.6 releases +directory</a>. Then extract this archive with the command "tar xvjf +linux-2.6.*.tar.bz2". (Type the command "man tar" for more information on the +tar command.) Then cd into the directory created by extracting the archive.</p> + +<p>To obtain other Linux kernel versions (such as development releases and +kernels supplied by <a href="#Distibutions">distributions</a>) +see <a href="Following_Linux_development">Following Linux development</a>.</p> + +<p>To return your linux kernel source directory to its original (unconfigured) +condition after configuring and building in it, either either delete the +directory with "rm -r" and re-extract it from the tar archive, or run the +command "make distclean".</p> +<h2><a href="#2.1.2" name="Configuring">2.1.2 Configuring</a></h2> +<span id="Configuring"> + +<p>Before you can build the kernel, you have to configure it. Configuring +selects which features this kernel build should include, and specifies other +technical information such as buffer sizes and optimization strategies. +This information is stored in a file named ".config" in the top level directory +of the kernel source code. To see the various user interfaces to the +configuration system, type "<a href=makehelp.txt>make help</a>".</p> + +<p>Note that "make clean" does not delete configuration information, but the +more thorough "make distclean" does.</p> + +<h2><a href="#2.1.2.1" name="Using_an_existing_configuration">2.1.2.1 Using an existing configuration</a></h2> +<span id="Using an existing configuration"> + +<p>Often when building a kernel, an existing .config file is supplied from +elsewhere. Copy it into place, and optionally run "make oldconfig" to run +the kernel's diagnostics against it to ensure it matches the kernel version +you're using, updating anything that's out of sync.</p> + +<p>Several preset configurations are shipped with the kernel source code. +Run the command <b>find . -name "*_defconfig"</b> in the kernel source +directory to seem them all. Any of these can be copied to .config and +used as a starting point.</p> + +<p>The kernel can also automatically generate various configurations, +mostly to act as starting points for customization:</p> +<ul> +<li><b>make defconfig</b> - Set all options to default values</li> +<li><b>make allnoconfig</b> - Set all yes/no options to "n"</li> +<li><b>make allyesconfig</b> - Set all yes/no options to "y"</li> +<li><b>make allmodconfig</b> - Set all yes/no options to "y" and all "yes/module/no" options to "m"</li> +<li><b>make randconfig</b> - Set each option randomly (for debugging purposes).</li> +<li><b>make oldconfig</b> - Update a .config file from a previous version of the kernel to work with the current version.</li> +</ul> + +<h2><a href="#2.1.2.2" name="Creating_a_custom_kernel_configuration">2.1.2.2 Creating a custom kernel configuration</a></h2> +<span id="Creating a custom kernel configuration"> +<p>The most common user interface for configuring the kernel is +<b>menuconfig</b>, an interactive terminal based menuing interface invoked +through the makefiles via "<b>make menuconfig</b>". This interface groups the +configuration questions into a series of menus, showing the current values +of each symbol and allowing them to be changed in any order. Each symbol +has associated help text, explaining what the symbol does and where to find +more information about it. This help text is +<a href=menuconfig>also available as html</a>.</p> + +<p>The menuconfig interface is controlled with the following keys:</p> + +<ul> +<li><b>cursor up/down</b> - move to another symbol</li> +<li><b>tab</b> - switch action between edit, help, and exit</li> +<li><b>enter</b> - descend into menu (or help/exit if you hit tab first)</li> +<li><b>esc</b> - exit menu (prompted to save if exiting top level menu)</li> +<li><b>space</b> - change configuration symbol under cursor</li> +<li><b>?</b> - view help for this symbol</li> +<li><b>/</b> - search for a symbol by name</li> +</ul> + +<p>Other configuration interfaces (functionally equivalent to menuconfig) +include:</p> +<ul> +<li><b>make config</b> - a simple text based question and answer interface +(which does not require curses support, or even a tty)</li> +<li><b>make xconfig</b> - QT based graphical interface</li> +<li><b>make gconfig</b> - GTK based graphical interface</li> +</ul> + +<h2><a href="#2.1.3" name="building">2.1.3 building</a></h2> +<span id="building"> + <h2><a href="#2.1.3.1" name="Building_out_of_tree">2.1.3.1 Building out of tree</a></h2> +<span id="Building out of tree"> + <h2><a href="#2.1.4" name="Installing">2.1.4 Installing</a></h2> +<span id="Installing"> + <h2><a href="#2.1.5" name="running">2.1.5 running</a></h2> +<span id="running"> + <h2><a href="#2.1.6" name="debugging">2.1.6 debugging</a></h2> +<span id="debugging"> + <h2><a href="#2.1.6.1" name="QEMU">2.1.6.1 QEMU</a></h2> +<span id="QEMU"> + <h2><a href="#2.1.7" name="cross_compiling">2.1.7 cross compiling</a></h2> +<span id="cross compiling"> +<h2><a href="#2.1.7.1" name="Cross_compiling_vs_native_compiling">2.1.7.1 Cross compiling vs native compiling</a></h2> +<span id="Cross compiling vs native compiling"> +<p>By default, Linux builds for the same architecture the host system is +running. This is called "native compiling". An x86 system building an x86 +kernel, x86-64 building x86-64, or powerpc building powerpc are all examples +of native compiling.</p> + +<p>Building different binaries than the host runs is called cross compiling. +<a href=http://landley.net/writing/docs/cross-compiling.html>Cross +compiling is hard</a>. The build system for the Linux kernel supports cross +compiling via a two step process: 1) Specify a different architecture (ARCH) +during the configure, make, and install stages. 2) Supply a cross compiler +(CROSS_COMPILE) which can output the correct kind of binary code. An +example cross compile command line (building the "arm" architecture) looks +like:</p> + +<blockquote> +<pre>make ARCH=arm menuconfig +make ARCH=arm CROSS_COMPILE=armv5l- +</pre> +</blockquote> + +<p>To specify a different architecture than the host, either define the "ARCH" +environment variable or else add "ARCH=xxx" to the make command line for each +of the make config, make, and make install stages. The acceptable values for +ARCH are the names of the directories in the "arch" subdirectory of the Linux +kernel source code, see <a href="#Architectures">Architectures</a> for +details. All stages of the build must use the same ARCH value, and building a +second architecture in the same source directory requires "make distclean". +(Just "make clean" isn't sufficient, things like the include/asm symlink need +to be removed and recreated.)</p> + +<p>To specify a cross compiler prefix, define the CROSS_COMPILE environment +variable (or add CROSS_COMPILE= to each make command line). Native compiler +tools, which output code aimed at the environment they're running in, usually +have a simple name ("gcc", "ld", "strip"). Cross compilers usually add a +prefix to the name of each tool, indicating the target they produce code for. +To tell the Linux kernel build to use a cross compiler named "armv4l-gcc" (and +corresponding "armv4l-ld" and "armv4l-strip") specify "CROSS_COMPILE=armv4l-". +(Prefixes ending in a dash are common, and forgetting the trailing dash in +CROSS_COMPILE is a common mistake. Don't forget to add the cross compiler +tools to your $PATH.)</p> +<h2><a href="#2.1.7.2" name="User_Mode_Linux">2.1.7.2 User Mode Linux</a></h2> +<span id="User Mode Linux"> + <h2><a href="#2.2" name="Infrastructure">2.2 Infrastructure</a></h2> +<span id="Infrastructure"> + <h2><a href="#2.2.1" name="kconfig">2.2.1 kconfig</a></h2> +<span id="kconfig"> +<p>The Linux configuration system is called Kconfig. The various +configuration front-ends (such as menuconfig) parse data files +written in the <a href=Documentation/kbuild/kconfig-language.txt>Kconfig language</a>, +which define the available symbols and provide default values, help entries, +and so on.</p> + +<p>The source code for the front ends is in scripts/kconfig. The +Makefile in this directory defines the make targets for the configuration +system.</p> + + <h2><a href="#2.2.2" name="kbuild">2.2.2 kbuild</a></h2> +<span id="kbuild"> + <h2><a href="#2.2.3" name="build_and_link_(tmppiggy)">2.2.3 build and link (tmppiggy)</a></h2> +<span id="build and link (tmppiggy)"> + <h2><a href="#3" name="Installing_and_using_the_kernel">3 Installing and using the kernel</a></h2> +<span id="Installing and using the kernel"> + <h2><a href="#3.1" name="Installing">3.1 Installing</a></h2> +<span id="Installing"> + <h2><a href="#3.1.1" name="Kernel_image">3.1.1 Kernel image</a></h2> +<span id="Kernel image"> + <h2><a href="#3.1.2" name="Bootloader">3.1.2 Bootloader</a></h2> +<span id="Bootloader"> + <h2><a href="#3.2" name="A_working_Linux_root_filesystem">3.2 A working Linux root filesystem</a></h2> +<span id="A working Linux root filesystem"> +<p><a href=ols/2002/ols2002-pages-176-182.pdf>Advanced Boot Scripts</a></p> + <h2><a href="#3.2.1" name="Finding_and_mounting__">3.2.1 Finding and mounting /</a></h2> +<span id="Finding and mounting /"> + <h2><a href="#3.2.1.1" name="initramfs,_switch_root_vs_pivot_root,__dev_console">3.2.1.1 initramfs, switch_root vs pivot_root, /dev/console</a></h2> +<span id="initramfs, switch_root vs pivot_root, /dev/console"> + <h2><a href="#3.2.2" name="Running_programs">3.2.2 Running programs</a></h2> +<span id="Running programs"> + <h2><a href="#3.2.2.1" name="init_program_and_PID_1">3.2.2.1 init program and PID 1</a></h2> +<span id="init program and PID 1"> + <h2><a href="#3.2.2.1.1" name="What_does_daemonizing_really_mean">3.2.2.1.1 What does daemonizing really mean?</a></h2> +<span id="What does daemonizing really mean?"> + <h2><a href="#3.2.2.2" name="Executable_formats">3.2.2.2 Executable formats</a></h2> +<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> + <h2><a href="#3.2.2.2.1" name="Shell_scripts">3.2.2.2.1 Shell scripts</a></h2> +<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> + <h2><a href="#3.2.2.2.2" name="ELF">3.2.2.2.2 ELF</a></h2> +<span id="ELF"> + <h2><a href="#3.2.2.2.2.1" name="Shared_libraries">3.2.2.2.2.1 Shared libraries</a></h2> +<span id="Shared libraries"> + <h2><a href="#3.2.2.3" name="C_library">3.2.2.3 C library</a></h2> +<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> + +<h2><a href="#3.2.2.3.1" name="Exporting_kernel_headers">3.2.2.3.1 Exporting kernel headers</a></h2> +<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=Documentation/make/headers_install.txt>exporting kernel headers for +use by userspace</a> for more information.</p> +<h2><a href="#3.2.2.4" name="Dynamic_loader">3.2.2.4 Dynamic loader</a></h2> +<span id="Dynamic loader"> + <h2><a href="#3.2.3" name="FHS_directories">3.2.3 FHS directories</a></h2> +<span id="FHS directories"> + <p>FHS spec</p> + <a href="pending/hotplug.txt">populating /dev from sysfs</a>. + <h2><a href="#4" name="Reading_the_source_code">4 Reading the source code</a></h2> +<span id="Reading the source code"> + <h2><a href="#4.1" name="Source_code_layout">4.1 Source code layout</a></h2> +<span id="Source code layout"> + <h2><a href="#4.1.1" name="Following_the_boot_process">4.1.1 Following the boot process</a></h2> +<span id="Following the boot process"> + <h2><a href="#4.1.2" name="Major_subsystems">4.1.2 Major subsystems</a></h2> +<span id="Major subsystems"> + <h2><a href="#4.1.3" name="Architectures">4.1.3 Architectures</a></h2> +<span id="Architectures"> + <h2><a href="#4.2" name="Concept_vs_implementation">4.2 Concept vs implementation</a></h2> +<span id="Concept vs implementation"> + <p>Often the first implementation of a concept gets replaced. + Journaling != reiserfs, virtualization != xen, devfs gave way to udev... + Don't let your excitement for the concept blind you to the possibility + of alternate implementations.</p> + <h2><a href="#4.3" name="Concepts">4.3 Concepts</a></h2> +<span id="Concepts"> + <h2><a href="#4.3.1" name="rbtree">4.3.1 rbtree</a></h2> +<span id="rbtree"> + <h2><a href="#4.3.2" name="rcu">4.3.2 rcu</a></h2> +<span id="rcu"> +<p>RCU stands for "Read Copy Update". The technique is a lockless way to manage data structures +(such as linked lists or trees) on SMP systems, using a specific sequence of reads and updates, +plus a garbage collection step, to avoid the need for locks in both the read and the update +paths.</p> + +<p>RCU was invented by Paul McKenney, who maintains an excellent page of +<a href=http://www.rdrop.com/users/paulmck/RCU/>RCU documentation</a>. +The Linux kernel also contains some <a href=Documentation/RCU>additional RCU +Documentation</a>.</p> + +<p>RCU cannot be configured out of the kernel, but the kconfig symbol +<a href=menuconfig/lib-Kconfig.debug.html#RCU_TORTURE_TEST>CONFIG_RCU_TORTURE_TEST</a> controls the +<a href=Documentation/RCU/torture.txt>RCU Torture test module</a>.</p> + +<p>References:</p> +<ul> +<li><a href=ols/2001/read-copy.pdf>Read-Copy Update</a> (OLS 2001)</li> +</ul> + + <h2><a href="#5" name="Kernel_infrastructure">5 Kernel infrastructure</a></h2> +<span id="Kernel infrastructure"> + <h2><a href="#5.1" name="Process_Scheduler">5.1 Process Scheduler</a></h2> +<span id="Process Scheduler"> + +<h2><a href="#5.1.1" name="History_of_the_Linux_Process_Scheduler">5.1.1 History of the Linux Process Scheduler</a></h2> +<span id="History of the Linux Process Scheduler"> +<p>The original Linux process scheduler was a simple design based on +a goodness() function that recalculated the priority of every task at every +context switch, to find the next task to switch to. This served almost +unchanged through the 2.4 series, but didn't scale to large numbers of +processes, nor to SMP. By 2001 there were calls for +change (such as the OLS paper <a href=ols/2001/elss.pdf>Enhancing Linux +Scheduler Scalability</a>), and the issue +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20020107_149.html#1>came to a head</a> in December 2001.</p> + +<p>In January 2002, Ingo Molnar +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20020114_150.html#4>introduced the "O(1)" process scheduler</a> for the 2.5 kernel series, a design +based on separate "active" and "expired" arrays, one per processor. As the name +implied, this found the next task to switch to in constant time no matter +how many processes the system was running.</p> + +<p>Other developers (<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20020513_166.html#4>such as Con Colivas</a>) started working on it, +and began a period of extensive scheduler development. The early history +of Linux O(1) scheduler development was covered by the website Kernel +Traffic.</p> + +<p>During 2002 this work included +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20020121_151.html#8>preemption</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20020121_151.html#9>User Mode Linux support</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20020211_153.html#2>new drops</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20020211_153.html#7>runtime tuning</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20020304_156.html#6>NUMA support</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20020429_164.html#4>cpu affinity</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20020617_171.html#4>scheduler hints</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20020701_173.html#1>64-bit support</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20020715_175.html#5>backports to the 2.4 kernel</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20020715_175.html#4>SCHED_IDLE</a>, +discussion of <a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20020729_177.html#1>gang scheduling</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20021014_188.html#4>more NUMA</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20021118_192.html#9>even more NUMA</a>). By the end of 2002, the O(1) scheduler was becoming +the standard <a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20021223_197.html#1>even in the 2.4 series</a>.</p> + +<p>2003 saw support added for +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20030124_202.html#14>hyperthreading as a NUMA variant</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20030330_211.html#3>interactivity bugfix</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20030616_219.html#4>starvation and affinity bugfixes</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20030616_219.html#8>more NUMA improvements</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20030811_227.html#2>interactivity improvements</a>, +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20030811_227.html#8>even more NUMA improvements</a>, +a proposal for <a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20031026_237.html#7>Variable Scheduling Timeouts</a> (the first rumblings of what +would later come to be called "dynamic ticks"), +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20031201_243.html#10>more on hyperthreading</a>...</p> + +<p>In 2004 there was work on <a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20040120_248.html#2>load balancing and priority handling</a>, and +<a href=http://mirell.org/kernel-traffic/kernel-traffic/kt20040212_252.html#5>still more work on hyperthreading</a>...</p> + +<p>In 2004 developers proposed several extensive changes to the O(1) scheduler. +Linux Weekly News wrote about Nick Piggin's +<a href=http://lwn.net/Articles/80911/>domain-based scheduler</a> +and Con Colivas' <a href=http://lwn.net/Articles/87729/>staircase scheduler</a>. The follow-up article <a href=http://lwn.net/Articles/96554/>Scheduler tweaks get serious</a> covers both. Nick's scheduling domains +were merged into the 2.6 series.</p> + +<p>Linux Weekly News also wrote about other scheduler work:</p> + +<ul> +<li><a href=http://lwn.net/Articles/83633/>Filtered wakeups</a></li> +<li><a href=http://lwn.net/Articles/105366/>When should a process be migrated</a></li> +<li><a href=http://lwn.net/Articles/109458/>Pluggable and realtime schedulers</a></li> +<li><a href=http://lwn.net/Articles/120797/>Low latency for audio applications:</a></li> +<li><a href=http://lwn.net/Articles/176635/>Solving starvation problems in the scheduler:</a></li> +<li><a href=http://lwn.net/Articles/186438/>SMPnice</a></li> +</ul> + +<p>In 2007, Con Colivas proposed a new scheduler, <a href=http://lwn.net/Articles/224865/>The Rotating Staircase Deadline Scheduler</a>, which +<a href=http://lwn.net/Articles/226054/>hit a snag</a>. Ingo +Molnar came up with a new scheduler, which he named the +<a href=http://lwn.net/Articles/230501/>Completely Fair Scheduler</a>, +described in the LWN writeups +<a href=http://lwn.net/Articles/230574/>Schedulers: the plot thickens</a>, +<a href=http://lwn.net/Articles/231672/>this week in the scheduling discussion</a>, and +<a href=http://lwn.net/Articles/240474/>CFS group scheduling</a>.</p> + +<p>The CFS scheduler was merged into 2.6.23.</p> +<h2><a href="#5.1.2" name="fork,_exec">5.1.2 fork, exec</a></h2> +<span id="fork, exec"> + <h2><a href="#5.1.3" name="sleep">5.1.3 sleep</a></h2> +<span id="sleep"> + <h2><a href="#5.1.4" name="realtime">5.1.4 realtime</a></h2> +<span id="realtime"> +<p><a href=ols/2001/rtai.pdf>The Real-Time Application Interface</a> (OLS 2001, obsolete)</a></p> + <h2><a href="#5.2" name="Timers">5.2 Timers</a></h2> +<span id="Timers"> + <h2><a href="#5.2.1" name="Interrupt_handling">5.2.1 Interrupt handling</a></h2> +<span id="Interrupt handling"> + <h2><a href="#5.3" name="memory_management">5.3 memory management</a></h2> +<span id="memory management"> + <ul> + <li><a href="gorman">Understanding the Linux Virtual Memory Manager</a>, online book by Mel Gorman.</li> + <li> What every programmer should know about memory, article series by Ulrich Drepper, +parts +<a href=http://lwn.net/Articles/250967/>one</a>, +<a href=http://lwn.net/Articles/252125/>two</a>, +<a href=http://lwn.net/Articles/253361/>three</a>, +<a href=http://lwn.net/Articles/254445/>four</a>, +<a href=http://lwn.net/Articles/255364/>five</a>. +</li> + <li>Ars technica ram guide, article series by Jon "Hannibal" Stokes, parts +<a href=http://arstechnica.com/paedia/r/ram_guide/ram_guide.part1-1.html>one</a>, +<a href=http://arstechnica.com/paedia/r/ram_guide/ram_guide.part1-1.html>two</a>, +<a href=http://arstechnica.com/paedia/r/ram_guide/ram_guide.part3-1.html>three</a></li> + </ul> + <h2><a href="#5.3.1" name="mmap,_DMA">5.3.1 mmap, DMA</a></h2> +<span id="mmap, DMA"> + <h2><a href="#5.4" name="vfs">5.4 vfs</a></h2> +<span id="vfs"> + <h2><a href="#5.4.1" name="Pipes,_files,_and_ttys">5.4.1 Pipes, files, and ttys</a></h2> +<span id="Pipes, files, and ttys"> +<p>A pipe can be read from or written to, transmitting a sequence of bytes +in order.</p> + +<p>A file can do what a pipe can, and adds the ability to seek to a location, +query the current location, and query the length of the file (all of which are +an integer number off bytes from the beginning of the file).</p> + +<p>A tty can do what a pipe can, and adds a speed (in bits per second) +and cursor location (X and Y, with the upper left corner at 0,0). Oh, and +you can make it go beep.</p> + +<p>Note that you can't call lseek() on a tty and you can't call termios +(man 3 termios) functions on a file. Each can be treated as a pipe.</p> + <h2><a href="#5.4.2" name="Filesystems">5.4.2 Filesystems</a></h2> +<span id="Filesystems"> + <h2><a href="#5.4.2.1" name="Types_of_filesystems_(see__proc_filesystems)">5.4.2.1 Types of filesystems (see /proc/filesystems)</a></h2> +<span id="Types of filesystems (see /proc/filesystems)"> + <h2><a href="#5.4.2.1.1" name="Block_backed">5.4.2.1.1 Block backed</a></h2> +<span id="Block backed"> +<h2><a href="#5.4.2.1.1.1" name="ext2">5.4.2.1.1.1 ext2</a></h2> +<span id="ext2"> + <ul> + <li><a href=ols/2002/ols2002-pages-117-129.pdf>Online ext2 and ext3 Filesystem Resizing</a> (OLS 2002)</li> + </ul> +<h2><a href="#5.4.2.1.1.2" name="jffs2">5.4.2.1.1.2 jffs2</a></h2> +<span id="jffs2"> + <ul> + <li><a href=ols/2001/jffs2.pdf>JFFS: The Journalling Flash Filesystem</a> (OLS 2001)</li> + </ul> +<h2><a href="#5.4.2.1.1.3" name="vxfs">5.4.2.1.1.3 vxfs</a></h2> +<span id="vxfs"> +<ul> + <li><a href=menuconfig/fs-Kconfig.html#VXFS_FS>CONFIG_VXFS_FS</a></li> + <li><a href=ols/2002/ols2002-pages-191-196.pdf>Reverse engineering an advanced filesystem</a></li> +</ul> +<h2><a href="#5.4.2.1.2" name="Ram_backed">5.4.2.1.2 Ram backed</a></h2> +<span id="Ram backed"> + <h2><a href="#5.4.2.1.2.1" name="ramfs">5.4.2.1.2.1 ramfs</a></h2> +<span id="ramfs"> + <h2><a href="#5.4.2.1.2.2" name="tmpfs">5.4.2.1.2.2 tmpfs</a></h2> +<span id="tmpfs"> + <h2><a href="#5.4.2.1.3" name="Synthetic">5.4.2.1.3 Synthetic</a></h2> +<span id="Synthetic"> + <h2><a href="#5.4.2.1.3.1" name="proc">5.4.2.1.3.1 proc</a></h2> +<span id="proc"> + <h2><a href="#5.4.2.1.3.2" name="sys">5.4.2.1.3.2 sys</a></h2> +<span id="sys"> +<p>Although the sysfs filesystem probably wasn't intentionally named after the +greek myth about pushing a rock to the top of a hill only to see it forever +roll back down again, this is a remarkably accurate analogy for the +task of documenting sysfs.</p> + +<p>The maintainers of sysfs do not believe in a stable API, and change +userspace-visible elements from release to release. The rationale is that +sysfs exports information from inside the kernel to outside the kernel +(what API doesn't?) and the kernel internals change, thus sysfs changes to +reflect it. This doesn't explain why sysfs regularly changes things that aren't +dictated by kernel internals, such as moving partition directories under block +device directories after initially exporting them at the same level, moving +/sys/block into /sys/devices, removing the "devices" symlink, and so on.<p> + +<p>In reality, sysfs is treated as a private API exported for the use of the +"udev" program, which is maintained by the same developers as sysfs. Any +attempt to use sysfs directly from other programs is condemned by sysfs' +authors as an abuse of sysfs, and attemps to document it are actively resisted +and ridiculed. (Yes, you must often update udev when you update the kernel.)</p> + +<p>The following documentation reflects the current state of sysfs. This is +likely to change in future, as its maintainers break compatability with +existing userspace programs they didn't personally write.</p> + + <h2><a href="#5.4.2.1.3.3" name="internal_(pipefs)">5.4.2.1.3.3 internal (pipefs)</a></h2> +<span id="internal (pipefs)"> + <h2><a href="#5.4.2.1.3.4" name="usbfs">5.4.2.1.3.4 usbfs</a></h2> +<span id="usbfs"> +http://www.linux-usb.org/USB-guide/x173.html +http://www.linux-usb.org/USB-guide/c607.html +http://www.linuxjournal.com/article/7466 + <h2><a href="#5.4.2.1.3.5" name="devpts">5.4.2.1.3.5 devpts</a></h2> +<span id="devpts"> + <h2><a href="#5.4.2.1.3.6" name="rootfs">5.4.2.1.3.6 rootfs</a></h2> +<span id="rootfs"> + <h2><a href="#5.4.2.1.3.7" name="devfs_(obsolete)">5.4.2.1.3.7 devfs (obsolete)</a></h2> +<span id="devfs (obsolete)"> +<p>Devfs was the first attempt to do a dynamic /dev directory which could change +in response to hotpluggable hardware, by doing the seemingly obvious thing of +creating a kernel filesystem to mount on /dev which would adjust itself as +the kernel detected changes in the available hardware.</p> + +<p>Devfs was an interesting learning experience, but turned out to be the wrong +approach, and was replaced by sysfs and udev. Devfs was removed in kernel +version 2.6.18. See +<a href=local/hotplug-history.html>the history of hotplug</a> for details.</p> + + <h2><a href="#5.4.2.1.4" name="Network">5.4.2.1.4 Network</a></h2> +<span id="Network"> + <h2><a href="#5.4.2.1.4.1" name="nfs">5.4.2.1.4.1 nfs</a></h2> +<span id="nfs"> +<p><a href=ols/2001/nfsv4_ols.pdf>Linux NFS Version 4: Implementation and Administration</a> (OLS 2001)</a></p> + <h2><a href="#5.4.2.1.4.2" name="smb_cifs">5.4.2.1.4.2 smb/cifs</a></h2> +<span id="smb/cifs"> + <h2><a href="#5.4.2.1.4.3" name="FUSE">5.4.2.1.4.3 FUSE</a></h2> +<span id="FUSE"> + <h2><a href="#5.4.2.2" name="Filesystem_drivers">5.4.2.2 Filesystem drivers</a></h2> +<span id="Filesystem drivers"> + <h2><a href="#5.4.2.2.1" name="Using">5.4.2.2.1 Using</a></h2> +<span id="Using"> + <h2><a href="#5.4.2.2.2" name="Writing">5.4.2.2.2 Writing</a></h2> +<span id="Writing"> + <h2><a href="#5.5" name="Drivers">5.5 Drivers</a></h2> +<span id="Drivers"> + <h2><a href="#5.5.1" name="Filesystem">5.5.1 Filesystem</a></h2> +<span id="Filesystem"> + <h2><a href="#5.5.2" name="Block_(block_layer,_scsi_layer)">5.5.2 Block (block layer, scsi layer)</a></h2> +<span id="Block (block layer, scsi layer)"> + <h2><a href="#5.5.2.1" name="SCSI_layer">5.5.2.1 SCSI layer</a></h2> +<span id="SCSI layer"> + <ul> + <li><a href="Documentation/scsi">Documentation/scsi</a> scsi.txt scsi_mid_low_api.txt scsi-generic.txt scsi_eh.txt</li> + <li><a href="http://sg.torque.net/sg/p/sg_v3_ho.html">SCSI Generic (sg) HOWTO</a></li> + <li><a href="xmlman/man4/sd.html">man 4 sd</a></li> + <li><a href="http://www.t10.org/scsi-3.htm">SCSI standards</a></li> + <li><a href=ols/2002/ols2002-pages-40-49.pdf>Incrementally Improving the Linux SCSI Subsystem</a> (OLS 2002)</li> + </ul> + <h2><a href="#5.5.3" name="Character">5.5.3 Character</a></h2> +<span id="Character"> + <h2><a href="#5.5.3.1" name="serial">5.5.3.1 serial</a></h2> +<span id="serial"> + <h2><a href="#5.5.3.2" name="keyboard">5.5.3.2 keyboard</a></h2> +<span id="keyboard"> + <h2><a href="#5.5.3.3" name="tty">5.5.3.3 tty</a></h2> +<span id="tty"> + <h2><a href="#5.5.3.3.1" name="pty">5.5.3.3.1 pty</a></h2> +<span id="pty"> + <h2><a href="#5.5.3.4" name="audio">5.5.3.4 audio</a></h2> +<span id="audio"> + <h2><a href="#5.5.3.5" name="null">5.5.3.5 null</a></h2> +<span id="null"> + <h2><a href="#5.5.3.6" name="random_urandom">5.5.3.6 random/urandom</a></h2> +<span id="random/urandom"> +<p><a href=http://eprint.iacr.org/2006/086.pdf>Analysis of the Linux Random Number Generator</a> - Zvi Gutterman, Benny Pinkas, Tzachy Reinman (iacr 2006)</p> + <h2><a href="#5.5.3.7" name="zero">5.5.3.7 zero</a></h2> +<span id="zero"> + <h2><a href="#5.5.4" name="DRI">5.5.4 DRI</a></h2> +<span id="DRI"> + <h2><a href="#5.5.5" name="Network">5.5.5 Network</a></h2> +<span id="Network"> + <h2><a href="#5.6" name="Hotplug">5.6 Hotplug</a></h2> +<span id="Hotplug"> +<p><a href=http://kernel.org/ols/2001/hotplug.pdf>Hotpluggable devices and the Linux kernel</a> (OLS 2001)</p> +<p><a href=local/hotplug-history.html>The history of hotplug</a></p> + <h2><a href="#5.7" name="Input_core">5.7 Input core</a></h2> +<span id="Input core"> + <h2><a href="#5.8" name="Network">5.8 Network</a></h2> +<span id="Network"> +<pre> +physical + plip + serial/slip/ppp + ethernet +routing + ipv4 + ipv6 +</pre> +<p><a href=ols/2001/mipl.pdf>MIPL Mobile IPv6 for Linux in HUT Campus Network MediaPoli</a> (OLS 2001)</p> +<p><a href=ols/2001/sctp.pdf>Linux Kernel SCTP: The Third Transport</a> (OLS 2001)</p> +<p><a href=ols/2002/ols2002-pages-8-30.pdf>TCPIP Network Stack Performance in Linux Kernel 2.4 and 2.5</a></p> + <h2><a href="#5.9" name="Modules">5.9 Modules</a></h2> +<span id="Modules"> + <h2><a href="#5.9.1" name="Exported_symbols">5.9.1 Exported symbols</a></h2> +<span id="Exported symbols"> + <p>EXPORT_SYMBOL() vs EXPORT_SYMBOL_GPL()</p> + <p>List of exported symbols.</p> + <h2><a href="#5.10" name="Busses">5.10 Busses</a></h2> +<span id="Busses"> + <h2><a href="#5.11" name="Security">5.11 Security</a></h2> +<span id="Security"> + <h2><a href="#5.11.1" name="Traditional_Unix_security_model">5.11.1 Traditional Unix security model</a></h2> +<span id="Traditional Unix security model"> +Users, groups, files (rwx), signals. + <h2><a href="#5.11.2" name="More_complicated_security_models">5.11.2 More complicated security models</a></h2> +<span id="More complicated security models"> +<p>The traditional Unix security model is too simple to satisfy the +certification requirements of large corporate and governmental organizations, +so several add-on security models have been implemented to increase +complexity. There is some debate as to which of these (if any) are actually an +improvement.</p> + + <h2><a href="#5.11.2.1" name="Posix_capabilities">5.11.2.1 Posix capabilities</a></h2> +<span id="Posix capabilities"> +http://www.gentoo.org/proj/en/hardened/capabilities.xml + <h2><a href="#5.11.2.2" name="SELinux">5.11.2.2 SELinux</a></h2> +<span id="SELinux"> +<p><a href=ols/2001/selinux.pdf>Meeting Critical Security Objectives with Security-Enhanced Linux</a> (OLS 2001)</p> +<p><a href=ols/2002/ols2002-pages-65-72.pdf>SE Debian: how to make NSA SE LInux work in a distribution</a> (OLS 2002)</p> + <h2><a href="#5.11.3" name="Encryption">5.11.3 Encryption</a></h2> +<span id="Encryption"> +<p><a href=ols/2002/ols2002-pages-73-92.pdf>The Long Road to the Advanced Encryption Standard</a></p> + <h2><a href="#5.12" name="API_(how_userspace_talks_to_the_kernel)">5.12 API (how userspace talks to the kernel)</a></h2> +<span id="API (how userspace talks to the kernel)"> + <h2><a href="#5.12.1" name="Syscalls">5.12.1 Syscalls</a></h2> +<span id="Syscalls"> + <h2><a href="#5.12.2" name="ioctls">5.12.2 ioctls</a></h2> +<span id="ioctls"> + <h2><a href="#5.12.3" name="executable_file_formats">5.12.3 executable file formats</a></h2> +<span id="executable file formats"> + <h2><a href="#5.12.3.1" name="a.out">5.12.3.1 a.out</a></h2> +<span id="a.out"> + <h2><a href="#5.12.3.2" name="elf">5.12.3.2 elf</a></h2> +<span id="elf"> + <h2><a href="#5.12.3.2.1" name="css,_bss,_etc.">5.12.3.2.1 css, bss, etc.</a></h2> +<span id="css, bss, etc."> + <h2><a href="#5.12.3.3" name="scripts">5.12.3.3 scripts</a></h2> +<span id="scripts"> + <h2><a href="#5.12.3.4" name="flat">5.12.3.4 flat</a></h2> +<span id="flat"> + <h2><a href="#5.12.3.5" name="misc">5.12.3.5 misc</a></h2> +<span id="misc"> + <h2><a href="#5.12.4" name="Device_nodes">5.12.4 Device nodes</a></h2> +<span id="Device nodes"> + <h2><a href="#5.12.5" name="Pipes_(new_pipe_infrastructure)">5.12.5 Pipes (new pipe infrastructure)</a></h2> +<span id="Pipes (new pipe infrastructure)"> + <h2><a href="#5.12.6" name="Synthetic_filesystems_(as_API)">5.12.6 Synthetic filesystems (as API)</a></h2> +<span id="Synthetic filesystems (as API)"> + <h2><a href="#6" name="Hardware">6 Hardware</a></h2> +<span id="Hardware"> + <h2><a href="#6.1" name="Architectures">6.1 Architectures</a></h2> +<span id="Architectures"> +<p>Linux supports many more hardware platforms than its original PC. +The first modern port of Linux was to the DEC Alpha processor +[TODO: open sources]</p> + +<p>The most widely used modern ports are i386, x86-64, ARM, mips, and powerpc, +all of which are supported by the emulator <a href=http://qemu.org>QEMU</a>. +Bootable kernel and filesystem images for those platforms (bootable under +QEMU) are available <a href=http://landley.net/code/firmware>here</a>.</p> + +<p>Alpha, sparc, parisc, itanium are primarily of historical interest. +Each of those platforms used to have a bigger developer community than it +does now, but has peaked and gone into a pronounced decline.</p> + +<p>Most of the other platforms have special-purpose niches. For example, +super-hitachi is widely used in the Japanese auto industry.</p> + +<pre> +avr32 +blackfin +cris +frv +h8300 +i386 +m32r +m68k +s390 +sh +sh64 +sparc +sparc64 +v850 +xtensa + +</pre> +<h2><a href="#6.1.1" name="alpha">6.1.1 alpha</a></h2> +<span id="alpha"> +<p>The now-obsolete +<a href=http://en.wikipedia.org/wiki/DEC_Alpha>DEC Alpha</a> was one of the +first 64-bit processors, one of the fastest and cleanest processor +designs of its time, and still has fans to this day. Despite excellent +performance and widespread use in supercomputers, manufacturing of +Alpha was +<a href=http://news.zdnet.co.uk/hardware/0,1000000091,2127122,00.htm>repeatedly +disrupted</a> and a series of acquisitions by PC vendors uninterested in any +non-PC architecture. Despite pressure from users and even +<a href=http://www.ftc.gov/opa/1998/04/digitala.shtm>government intervention</a> +to preserve the Alpha processor, new development of the hardware ceased +towards the end of the 1990's.</p> + +<p>The legacy of Alpha lives on in the x86-64 architecture. When +<a href=http://www.chron.com/content/chronicle/page1/98/01/27/com.html>Compaq +bought DEC</a> it acquired the rights to the Alpha processor, but not the +chip design team. Many ex-Alpha chip designers wound up at AMD, where they +<a href=http://arstechnica.com/cpu/3q99/athlon/athlon-1.html>designed +the Athlon</a> (x86) and Opteron (x86-64) processors. Intel also +<a href=http://www.news.com/Compaq-Life-after-Alpha/2100-1001_3-268986.html?tag=st.ref.goo>licensed</a> and <a href=http://www.news.com/Intel-hyperthreading-shows-Digital-roots/2100-1001_3-961495.html?tag=st.ref.goo>incorporated</a> +Alpha technology into all its processor lines. Internally, modern PC +processors owe more to the Alpha than to the original 8086 processor.</p> + +<p>Alpha is of great historical importance to Linux as the +<a href=http://www.oreilly.com/catalog/opensources/book/linus.html>first non-PC +port incorporated into Linus's tree</a>, as well as the first 64-bit port. +<a href=http://qemu.org>QEMU</a> recently grew preliminary support for +emulating Alpha processors.</a> + +<ul> +<li><a href=http://www.alphalinux.org/>AlphaLinux.org</a></li> +</ul> + +<h2><a href="#6.1.2" name="arm">6.1.2 arm</a></h2> +<span id="arm"> +<p>The ARM processor is the most popular embedded processor, powering 80-90% of +the cell phone market and most battery powered handheld devices. The iPod, +iPhone, Nokia N800, and Nintendo DS are all ARM-based.</p> + +<p>While the x86 family has the world's leading price/performance ratio, +the ARM processor family has the best ratio power consumption to performance. +By delivering the best bang for the watt, ARM has become overwhelmingly popular +in embedded devices.</p> + +<p>ARM originally for "Acorn RISC Machine", a processor designed by a British +company in the early 80's to replace the 8-bit 6502 in Acorn's successful BBC +Micro. Unlike most RISC design efforts which focused on using RISC techniques +to increase performance, Acorn focused on creating a small, simple processor +design, initially with under 25,000 transistors (these days with about 43,000 +transistors worth of core logic, before adding a cache and memory controller). +In 1990, the processor design team moved to a new company, +<a href=http://www.arm.com>ARM Ltd</a>, which doesn't manufacture chips but +instead licenses its designs to other companies interested in fabricating +chips. This also allows ARM designs to be easily customized, and +embedded in things like network cards or system-on-chip designs.</p> + +<p>Arm processor generations are divided by "architecture", which among other +things indicates the instruction set the processor can run:</p> +<ul> +<li>ARMv3 - The oldest 32-bit ARM architecture, now considered obsolete.</li> +<li>ARMv4 - The oldest architecture still in widespread use.</li> +<li>ARMv5 - The oldest architecture still in production. The baseline +modern" architecture.</li> +<li>ARMv6,v7 - An architecture ARM inc has used NDA terms to prevent QEMU +developers from releasing support for (apparently because it wants to sell +proprietary emulators, and considers a GPLed emulator a threat). These +processors run ARMv4/v5 code.</li> +</ul> + +<p>The newest archtecture that can be emulated by +<a href=http://qemu.org>QEMU</a> is ARMv5TEJ (I.E. ARMv5 +with the Thumb, Enhanced DSP, and Java extensions). Unfortunately, ARM Ltd. +has leveraged its NDAs with prominent open source developers to +<a href=http://lists.gnu.org/archive/html/qemu-devel/2007-02/msg00426.html>explicitly +forbid</a> them from contributing ARMv6 support to QEMU, apparently because +it's trying to sell a competing proprietary emulation product.</p> + +<p>Newer ARM processors run older instruction sets, and are thus backwards +compatible. The advantage of newer instruction sets is that they execute +faster (and are thus more energy efficient), and some produce smaller binary +sizes (the "Thumb" extensions are designed specifically for small code size, +but may exchange performance to get it). Recompiling an ARMv4 program as ARMv5 +usually results in a 25% performance improvement.</p> + +<ul> +<li><a href="http://www.arm.com/products/CPUs/architecture.html">The ARM instruction set architecture</a> +<li><a href="http://www.elinux.org/ARM_Processor">List of ARM processors</a></li> +<li><a href="http://www.arm.linux.org.uk">The ARM Linux web page</a></li> +<li><a href=http://www.arm.linux.org.uk/developer/machines/>List of +over 1500 known arm systems</a>.</li> +<li><a href=http://www.ot1.com/arm/armchap1.html>History of the ARM CPU</a></li> +</ul> +<h2><a href="#6.1.3" name="ia64">6.1.3 ia64</a></h2> +<span id="ia64"> +<p>The Itanium was a failed attempt to create a 64-bit successor to the x86, a +role that went to AMD's x86-64 design instead. In 1994, Intel partnered with +HP to produce a successor to both x86 and HP's PA-RISC, with a new instruction +set ("ia64") fundamentally different from both. To support software written +for the older processors, the designers included a complete implementation of +each, because the new chip was already so big and complex that including _two_ +entire previous processors wasn't a significant increase to either. (If this +sounds unlikely to end well...)</p> + +<p>The result was a late, slow, inefficient chip that was difficult to +manufacture, more expensive than available alternatives, difficult to write +efficient compilers for, quickly nicknamed "Itanic" and essentially ignored by +the market. (This was remarkably similar to Intel's earlier +<a href=http://en.wikipedia.org/wiki/Intel_iAPX_432>i432 project</a>, +a 1970's attempt to jump straight from the 8 bit 8080 to a +32-bit processor which also resulted resulted in a slow, late, overcomplicated +and overpriced design which the industry ignored. The i432 was finally killed +off by the arrival of the 80286, which outperformed it by a factor of four. +History does repeat itself.)</p> + +<p>For comparison purposes, the +<a href=http://www.failuremag.com/arch_history_edsel.html>Ford Edsel</a> sold +64,000 units in its first year. Itanium took over four years to sell that +many: +only <a href=http://news.com.com/2100-1001-276880.html?tag=nl>500 units in +2001</a>, <a href=http://www.theinquirer.net/?article=7983>3,500 in 2002</a>, +and around +<a href=http://www.theregister.co.uk/2005/02/28/itanium_04_sales/>19,000 in +2003 and 30,000 in 2004</a>. In 2005, x86-64 systems emerged as the new +64-bit PC standard, at which point Dell and IBM discontinued their Itanium +servers and HP discontinued its Itanium workstations.</p> + +<p>To give a <a href=http://media.corporate-ir.net/media_files/irol/19/197211/press/Q12007EarningsRelease.pdf>sense of perspective</a>, in the first quarter of +2007, the licensees of ARM Inc. shipped 724 million ARM processors. (In one +quarter, not a full year.) In the third quarter of 2007, the PC market shipped +<a href=http://www.news.com/8301-10784_3-9825843-7.html>http://www.news.com/8301-10784_3-9825843-7.html>68.1 million</a> systems (mostly x86-64). +Over in <a href=http://www.wikinvest.com/concept/Game_Consoles_Wars:_Xbox_360_vs._PS3_vs._Wii>PowerPC land</a>, +from their launch through August 2007 the Wii had sold 9 million units, Xbox +360 8.9 million, and Playstation 3 3.7 million (all three PowerPC based). +Shipments of +<a href=http://www.mdronline.com/publications/epw/issues/epw_31.html>many other +interesting processor families</a> each number in the millions of units +annually</a>. The Itanium's cumulative total of 0.05 million +in its first four years combined doesn't even show up on the same graph.</p> + +<p>The history of Itanium through 2003 was extensively detailed +<a href=http://www.catb.org/~esr/halloween/halloween9.html#itanium>here</a>. +A more recent obituary for the chip is zdnet's +<a href=http://news.zdnet.com/2100-9584_22-5984747.html>Itanium: A cautionary +tale</a>.</p> + +<p>Despite the Itanium's failure to gain any marketplace traction +(and <a href=http://www.theinquirer.net/en/inquirer/news/2003/02/24/linus-torvalds-itanium-threw-out-all-the-good-parts-of-the-x86>Linus Torvalds' +personal disdain for the chip</a>, the billions +of dollars poured into Itanium resulted in lots of corporate engineers assigned +to developing extensive Linux support for this virtually nonexistent hardware. +But despite a documented instruction set, no open source emulators run Itanium +code due to lack of interest. (HP does offer a binary-only Itanium +emulator called +<a href=http://www.hpl.hp.com/research/linux/ski/download.php>SKI</a>, last +updated in 2004.)</p> + +<p>Silicon Graphics still produces Itanium systems. HP no longer produces +Itanium workstations, but offers some Itanium servers. Intel still spends +money on it.</p> + +<h2><a href="#6.1.4" name="m68knommu">6.1.4 m68knommu</a></h2> +<span id="m68knommu"> +<p>The most popular nommu 68k variant is Coldfire, which uses a subset of the +68k instruction set and has no memory management unit. Coldfire is currently +used in a small number of high volume devices. (I.E. Coldfire isn't used in +many different products, but the products it's used in are produced in high +volume.)</p> + +<p><a href=ols/2002/ols2002-pages-130-145.pdf>Running Linux on a DSP: Exploiting the Computational Resources of a programmable DSP Micro-Processor with uClinux</a> (OLS 2002)</p> +<h2><a href="#6.1.5" name="mips">6.1.5 mips</a></h2> +<span id="mips"> +<p>Mips is probably the main competitor to ARM. One advantage of MIPS is its +availability as a FPGA program, allowing easy prototyping of custom +hardware.</p> + +<p>SGI produced primarily MIPS systems back in the Irix days. Sony's +Playstation 2, and PSP are MIPS based, as are some Tivo and Linksys devices.</p> + +<p><a href=http://en.wikipedia.org/wiki/MIPS_architecture>MIPS architecture</a></a> +<p><a href=http://linux-mips.org>The Linux/MIPS web page</a></p> + +<h2><a href="#6.1.6" name="parisc">6.1.6 parisc</a></h2> +<span id="parisc"> +<p>The PA-RISC is from Hewlett Packard. It was scheduled to be discontinued in +favor of the Itanium, but the failure of ia64 led to a restart of +PA-RISC development.</p> + + <a href=ols/2002/ols2002-pages-183-190.pdf>Porting Drivers to HP ZX1</a> +<h2><a href="#6.1.7" name="powerpc">6.1.7 powerpc</a></h2> +<span id="powerpc"> +<p>The PowerPC was created in the early 90's by a parnership between IBM, +Apple, and Motorola. Apple switched to x86-64 in 2005 and Motorola spun off +its processor division as Freescale (which now also manufactures Coldfire and +ARM processors). But IBM is still strongly behind PowerPC, and the various +users of PowerPC formed a <a href=http://powerpc.org>consortium</a> to +promote and develop it.</p> + +<p>PowerPC is commonly used in high volume set-top boxes and game consoles +such as the PlayStation 3, Xbox and Xbox 360, and Nintendo Wii. PowerPC +is the third most common processor type in the +<a href=http://top500.org>Top 500</a> supercomputers list, and was used in +older cell phones (before Motorola spun off Freescale).</p> + +<p>The most interesting recent PowerPC development is the <a href=http://en.wikipedia.org/wiki/Cell_microprocessor>Cell processor</a>, +which combines a PowerPC core with 8 DSP-like "synergistic processing +units" which can offload compute-intensive tasks like 3D acceleration, +compression, encryption, and so on.</p> + +<p>The PowerPC 7xx is the "386" of PowerPC systems, meaing most modern PowerPC +processors can run code compiled fro PowerPC 7xx (although such older code +may not take full advantage of the new chip's capabilities, especially +with regard to performance). The PowerPC family also has +<a href=http://en.wikipedia.org/wiki/PowerPC_970>64-bit variants</a> (an +early version of which Apple marketed as the "G5") that can still run 32-bit +PowerPC code.</p> + +<p>The main exceptions to 7xx compatability are two embedded subsets of the +PowerPC, which were separately developed by IBM (the 4xx series) and Motorola +(the 8xx series) for use in low power devices. These are stripped down PowerPC +processors in roughly the same way Coldfire was a stripped down 68k: +instructions were removed from the architecture to get the transistor count +down, and thus code must be recompiled to avoid using those instructions. +Unfortunately, the two vendors chose a different subset of the PowerPC +instruction set, so code compiled for 4xx won't run on 8xx, and vice versa.</p> + +<p>The 4xx line was purchased by <a href=http://www.amcc.com/Embedded/>AMCC</a> +(which has the most annoying website design ever, click one of the tabs to +get it to STOP MOVING). Freescale mostly seems to have lost interest in the +8xx now that Motorola has switched its' cell phones to arm, but information +is <a href=http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=0162468rH3bTdGJk194204>still available</a>.</p> + +<p>The Linux PowerPC developers hang out on the #mklinux channel on +irc.freenode.net.</p> + + <a href=ols/2001/iseries.pdf>The Linux Kernel on iSeries</a> (OLS 2001) + <a href=ols/2001/ppc64.pdf>PowerPC 64-bit Kernel Internals</a> (OLS 2001) + <a href=http://perso.magic.fr/l_indien/qemu-ppc/PowerPC_ref/PowerPC_ref.html>PowerPC implementation reference for QEMU</a> +<h2><a href="#6.1.8" name="ppc">6.1.8 ppc</a></h2> +<span id="ppc"> +<p>The "ppc" architecture is obsolete, and +<a href="Documentation/feature-removal-schedule.txt">scheduled for removal +in June 2008</a>.</p> + +<p>Once upon a time, ARCH=ppc was for 32-bit PowerPC processors (7xx and up), +and ARCH=powerpc was for 64-bit (970/G5 and up), but the two architectures were +merged together and support for most boards has since been ported over to +powerpc. If you care about any of the remaining boards, bug the powerpc +maintainers.</p> + +<p>Note that ARCH=ppc does not support newer features like "make +headers_install", but ARCH=powerpc does.</p> +<h2><a href="#6.1.9" name="um">6.1.9 um</a></h2> +<span id="um"> +<p>User Mode Linux is a port of Linux to run as a userspace program. Instead +of talking to the hardware, it makes system calls to the C library. Instead +of using a memory managment unit it makes clever use of mmap.</p> + +<p>UML is sort of like an emulator: it can run Linux programs under itself +(its processes show up as threads to the host system). It's sometimes used +as a superior "fakeroot", and sometimes used to provide an emulated system +for honeypots or shared hosting services. It's an excellent tool for +learning and debugging the Linux kernel, because you can use all the normal +userspace debugging techniques, up to and including putting "printf()" +statements into the source code to see what it's doing. (It's great for +developing things like filesystems, not so good for device drivers.)</p> + +<ul> +<li><a href=ols/2001/uml.pdf>User-Mode Linux</a> (OLS 2001)</li> +<li><a href=ols/2002/ols2002-pages-107-116.pdf>Making Linux Safe for Virtual Machines</a> (OLS 2002)</li> +<li><a href=http://landley.net/writing/docs/UML.html>User Mode Linux HOWTO</a></li> +</ul> +<h2><a href="#6.1.10" name="x86_64">6.1.10 x86_64</a></h2> +<span id="x86_64"> +<p><a href=http://x86-64.org>x86-64</a> is the 64-bit successor to x86, and +the new dominant PC processor. Essentially all current PCs are now shipping +with x86-64 processors, including traditionally non-x86 architectures such +as Apple's Macintosh and Sun's servers.</p> + + + <a href=ols/2001/x86-64.pdf>Porting Linux to x86-64</a> (OLS 2001) +</pre> + <h2><a href="#6.2" name="DMA,_IRQ,_MMU_(mmap),_IOMMU,_port_I_O">6.2 DMA, IRQ, MMU (mmap), IOMMU, port I/O</a></h2> +<span id="DMA, IRQ, MMU (mmap), IOMMU, port I/O"> + <h2><a href="#6.3" name="Busses">6.3 Busses</a></h2> +<span id="Busses"> + <h2><a href="#6.3.1" name="PCI,_USB">6.3.1 PCI, USB</a></h2> +<span id="PCI, USB"> +http://www.linux-usb.org/USB-guide/book1.html +Documentation/usb +<p><a href=ols/2001/pci.pdf>PCIComm: A Linux Device Driver for Communication over PCI Shared Memory</a> (OLS 2001)</p> +<p><a href=ols/2001/powertweak.pdf>Linux performance tuning using Powertweak</a> (OLS 2001)</p> + <h2><a href="#7" name="Following_Linux_development">7 Following Linux development</a></h2> +<span id="Following Linux development"> + <h2><a href="#7.1" name="Distibutions">7.1 Distibutions</a></h2> +<span id="Distibutions"> + <h2><a href="#7.2" name="Releases">7.2 Releases</a></h2> +<span id="Releases"> + <h2><a href="#7.2.1" name="Source_control">7.2.1 Source control</a></h2> +<span id="Source control"> + +<p>Linux releases from 0.0.1 through 2.4.x used no source control system, just +release tarballs. Releases 2.5.0 through 2.6.12-rc2 used a proprietary +source control system called BitKeeper. Releases 2.6.12-rc2 through the +present use a source control system called git.</p> + +<p>Early Linux development didn't use source control. Instead Linus would +apply patches to his copy of the source, and periodically release tarball +snapshots of his development tree with a hand-edited changelog file noting who +contributed each patch he'd applied. Most of these patches were posted to the +Linux Kernel Mailing List, and with a little effort could be fished out of the +mailing list archives.</p> + +<p>This worked for many years, but didn't scale as Linux development grew. +Eventually the issue came to a head [link], and after some discussion Linus +decided to use a proprietary distributed source control system called +BitKeeper for the 2.5 development branch. Linux releases v2.5.0 through +v2.6.12-rc2 were put out this way.</p> + +<p>Linux development no longer uses BitKeeper, due to the sudden +<a href=http://lwn.net/Articles/130746/>expiration of the +"Don't piss off Larry license"</a> under which BitKeeper was made available +to the Linux community (<a href=http://lwn.net/Articles/132938/>more here</a>). +This prompted Linus to take a month off from Linux development to write his own +distributed source control system, git. This is why the current source control +history in the main git development repository goes back to 2.6.12-rc2. +(The revision history from the BitKeeper era was later +<a href=http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=summary>converted to git</a>, but remains separate for historical reasons.)</p> + +<p>Linus initially chose BitKeeper because he wanted a distributed source +control system, and the open source alternatives available at the time were +all centralized source control systems.</p> + +<p>In a distributed source control +system, every user has a complete copy of the project's entire revision +history, which they can add their own changes to locally. A centralized source +control system requires a single central location, with user accounts to +control access and either locking the tree or rejecting attempts to apply out +of date patches. A distributed source control system is instead designed to +download and merge changes from many different repositories after they're +checked in to those other repositories. The source control system handles +almost all of this merging automatically, because it can trace the changes in +each repository back to a common ancestor, and then use three-way merge +algorithms to better understand the changes. (Patches don't indicate +which version they apply to. A distributed source control system has +more information avialable to it, and uses that information to automatically +merge changes more effectively.)</p> + +<p>This allows Linux subsystem maintainers to develop +and test their own local versions, then send changes to Linus in large batches +(without smearing together the individual patches they committed), and finally +resync with Linus's repository to get everyone else's changes. Open source +development is already distributed, so distributed source control is a better +fit. In this development model, Linus's repository serves as a coordination +point, but not a development bottleneck for anything except putting out +releases (which come from Linus's repository).</p> + +<p>Linus described the appeal of distributed source control, and his reasons +for developing git, in the Google Video tech talk +<a href=http://video.google.com/videoplay?docid=-2199332044603874737>Linus Torvalds on git</a>.</p> + +<p>The linux kernel source is also available as a +<a href=http://kernel.org/hg/linux-2.6>mercurial repository</a>, another +popular open source distributed source control system.</p> + +<p>This paper still serves as a decent introduction to distributed source +control: <a href=http://kernel.org/doc/ols/2002/ols2002-pages-197-212.pdf>BitKeeper +for Kernel Development</a> (OLS 2002, obsolete)</p> + + <h2><a href="#7.3" name="community">7.3 community</a></h2> +<span id="community"> +<pre> + CATB + http://vger.kernel.org/vger-lists.html + http://www.tux.org/lkml/ + lwn, kernel traffic, kernelplanet. + http://www.kernel.org/faq + http://www.kernel.org/kdist/rss.xml + git/mercurial + Documentation/{CodingStyle,SubmitChecklist} + The four layer (developer, maintainer, subsystem, linus) model. + Politics + Stable API nonsense + Why reiser4 not in. +</pre> + <h2><a href="#7.4" name="Submitting_Patches">7.4 Submitting Patches</a></h2> +<span id="Submitting Patches"> + <h2><a href="#8" name="Glossary">8 Glossary</a></h2> +<span id="Glossary"> +</body> +</html>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/index.html Sat Feb 19 21:28:05 2011 -0600 @@ -0,0 +1,85 @@ +<html> +<title>Linux Kernel Documentation</title> +<body> + +<h2>Documentation extracted from the Linux kernel and mirrored on the web where +Google can find it:</h2> +<ul> +<li><p><a href=Documentation>Documentation</a> - Text files in the kernel source tarball's Documentation subdirectory.</p></li> +<li><p><a href=htmldocs>htmldocs</a> - Kernel Documentation maintained in docbook format (output of "make htmldocs").</p></li> +<li><p><a href=menuconfig>Menuconfig</a> - help text for each kernel configuration option (from kconfig source).</p></li> + +<li><p><a href=readme>README</a> various README files scattered around Linux kernel source</a></p></li> +<li><p><a href=rfc-linux.html>RFC</a> - List of IETF RFCs referred to by kernel source files. Links to both the text of the RFC and the source files that refer to it.</a></p></li> +<li><p><a href=makehelp.txt>Output of kernel's "make help".</a></p></li> +</ul> + +<h2>Standards documents applicable to the Linux kernel</h2> +<ul> +<li><p><a href=http://www.opengroup.org/onlinepubs/9699919799/>Single Unix Specification v4</a> (Also known as Open Group Base Specifications issue 7, and POSIX 2008. See especially <a href=http://www.opengroup.org/onlinepubs/9699919799/idx/xsh.html>system interfaces</a>)</p></li> + +<li><p>C99 standard (current version of the C programming language): <a href=http://www.open-std.org/jtc1/sc22/wg14/www/standards>ISO/IEC C9899 PDF</a>, <a href=http://busybox.net/~landley/c99-draft.html>html</a>, or <a href=http://c0x.coding-guidelines.com/>searchable website</a>.</p></li> +<li><p><a href=http://www.unix.org/whitepapers/64bit.html>LP64 standard</a> defining the size of char, short, int, and long on 32-bit and 64-bit platforms. (See also the <a href=http://www.unix.org/version2/whatsnew/lp64_wp.html>rationale</a> for the standard, and the <a href=http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx>legacy reasons</a> another OS declined to adopt this standard).</p></li> + +<li><p><a href=http://refspecs.linuxfoundation.org/index.shtml>Linux Foundation's specs page</a> (ELF, Dwarf, ABI...)</p></li> +<li><p><a href="http://www.t10.org/scsi-3.htm">SCSI standards</a></p></li> +</ul> + +<h2>Other web pages containing kernel documentation</h2> +<ul> +<li><p><a href=ols>Ottawa Linux Symposium papers, split up and indexed by year</a></p></li> +<li><a href=http://kernel.org/doc/man-pages>Linux man-pages website, includes HTML versions of man pages</a></li> +<li><p><a href=http://vger.kernel.org/vger-lists.html>Development mailing lists available on kernel.org</a></p></li> + +<li><p><a href=http://lwn.net/Kernel/Index/>All Linux Weekly News kernel articles</a> indexed by topic<p></li> +<li><p><a href=http://www.linuxjournal.com/xstatic/magazine/archives>Linux Journal archives</a></p></li> +<li><p><a href=http://twitter.com/kernellog2>H-Online's Kernel-Log</a> (most recent first)</p></li> +<li><p>Linux Device Drivers book (<a href=http://lwn.net/Kernel/LDD3/>third edition</a>) (<a href=http://www.xml.com/ldd/chapter/book/>second edition</a>)</p></li> +<li><p><a href=http://www.ibm.com/developerworks/views/linux/library.jsp>IBM Developerworks Linux Library</a> (also <a href=http://www.ibm.com/developerworks/linux/library/l-linux-kernel/>here</a>)</p></li> + +<li><p><a href=http://www.tux.org/lkml/>Linux Kernel Mailing List FAQ</a></p></li> +<li><p><a href=http://kernelplanet.org>Kernel Planet (blog aggregator)</a></p></li> +<li><p><a href=video.html>A few videos of interest</a></p></li> +<li><p><a href=local>Some locally produced docs</a></p></li> +<li><p><a href=als1999>Atlanta Linux Showcase CD (1999)</a></p></li> +</ul> + +<h2>Translations to other languages</h2> +<ul> +<li><p><a href=http://tlktp.sourceforge.net/>Linux Kernel Translation Project</a></p></li> + +<li><p><a href=http://kernelnewbies.org/RegionalNewbies>Kernel Newbies regional pages</a></p></li> +<li><p><a href=http://www.linux.or.jp/JF/index.html>Japanese</a></p></li> +<li><p><a href=http://zh-kernel.org/docs>Chinese</a></p></li> +</ul> + +<h2>Documentation on memory management</h2> +<ul> +<li><p><a href="gorman">Understanding the Linux Virtual Memory Manager</a>, online book by Mel Gorman.</p></li> +<li><p>What every programmer should know about memory, article series by Ulrich Drepper, +parts +<a href=http://lwn.net/Articles/250967/>one</a>, + +<a href=http://lwn.net/Articles/252125/>two</a>, +<a href=http://lwn.net/Articles/253361/>three</a>, +<a href=http://lwn.net/Articles/254445/>four</a>, +<a href=http://lwn.net/Articles/255364/>five</a>. +</p></li> +<li><p>Ars technica ram guide, article series by Jon "Hannibal" Stokes, parts +<a href=http://arstechnica.com/paedia/r/ram_guide/ram_guide.part1-1.html>one</a>, +<a href=http://arstechnica.com/paedia/r/ram_guide/ram_guide.part1-1.html>two</a>, +<a href=http://arstechnica.com/paedia/r/ram_guide/ram_guide.part3-1.html>three</a>, +<a href=http://arstechnica.com/articles/paedia/cpu/caching.ars/1>Cacheing</a>, + +<a href=http://arstechnica.com/articles/paedia/cpu/bandwidth-latency.ars>Bandwidth and Latency</a>.</p></li> +</ul> + +<h2>Miscelaneous</h2> +<ul> +<li><p><a href=index-old.html>Old index.</a></p></li> +</ul> + +<p>Page maintained by Rob Landley, rlandley at parallels dot com.</p> +</body> +</html> +