changeset 79:4b9263d24970

More links, and some material on the history of Linux source control.
author Rob Landley <>
date Tue, 23 Oct 2007 00:47:46 -0500
parents 307408bf8982
children fa8bf02e7cfa
files master.idx
diffstat 1 files changed, 113 insertions(+), 10 deletions(-) [+]
line wrap: on
line diff
--- a/master.idx	Thu Oct 18 19:22:09 2007 -0500
+++ b/master.idx	Tue Oct 23 00:47:46 2007 -0500
@@ -49,7 +49,7 @@
 <span id="Standards">
 <li><a href=>Single Unix Specification v3</a> (Also known as Open Group Base Specifications issue 6, and closely overlapping with Posix.  See especially <a href=>system interfaces</a>)</li>
-<li><a href=>ISO/IEC C9899</a> the "C99" standard, defining the C programming language.</a></li>
+<li>C99 standard (defining the C programming language): <a href=>ISO/IEC C9899 PDF</a> or <a href=>searchable website</a>.</li>
 <li><a href=>Linux Foundation's specs page</a> (ELF, Dwarf, ABI...)</li>
 </span id="Standards">
@@ -190,6 +190,7 @@
   <span id="A working Linux root filesystem">
+<p><a href=ols/2002/ols2002-pages-176-182.pdf>Advanced Boot Scripts</a></p>
     <span id="Finding and mounting /">
       <span id="initramfs, switch_root vs pivot_root, /dev/console">
@@ -278,8 +279,8 @@
 <p>Modern Linux kernels (based on 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>
+<a href=Documentation/make/headers_install.txt>exporting kernel headers for
+use by userspace</a> for more information.</p>
       <span id="Dynamic loader">
@@ -431,11 +432,17 @@
   <span id="memory management">
-    <li><a href="gorman">Understanding the Linux Virtual Memory Manager</a>, by Mel Gorman.</li>
-    <li><a href=>What every programmer should know about memory</a> by Ulrich Drepper.</li>
-    <li>Ars technica ram guide, parts
-<a href=>one</a>
-<a href=>two</a>
+    <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,
+<a href=>one</a>,
+<a href=>two</a>,
+<a href=>three</a>,
+<a href=>four</a>.
+    <li>Ars technica ram guide, article series by Jon "Hannibal" Stokes, parts
+<a href=>one</a>,
+<a href=>two</a>,
 <a href=>three</a></li>
     <span id="mmap, DMA">
@@ -460,7 +467,22 @@
     <span id="Filesystems">
       <span id="Types of filesystems (see /proc/filesystems)">
         <span id="Block backed">
-<p><a href=ols/2001/jffs2.pdf>JFFS: The Journalling Flash Filesystem</a> (OLS 2001)</p>
+<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>
+<span id="jffs2">
+  <ul>
+  <li><a href=ols/2001/jffs2.pdf>JFFS: The Journalling Flash Filesystem</a> (OLS 2001)</li>
+  </ul>
+<span id="vxfs">
+  <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>
         <span id="Ram backed">
           <span id="ramfs">
@@ -526,6 +548,7 @@
         <li><a href="">SCSI Generic (sg) HOWTO</a></li>
 	<li><a href="xmlman/man4/sd.html">man 4 sd</a></li>
         <li><a href="">SCSI standards</a></li>
+        <li><a href=ols/2002/ols2002-pages-40-49.pdf>Incrementally Improving the Linux SCSI Subsystem</a> (OLS 2002)</li>
@@ -571,6 +594,7 @@
 <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>
   <span id="Modules">
     <span id="Exported symbols">
@@ -591,13 +615,17 @@
 complexity.  There is some debate as to which of these (if any) are actually an
-<p><a href=ols/2001/selinux.pdf>Meeting Critical Security Objectives with Security-Enhanced Linux</a> (OLS 2001)</p>
       <span id="Posix capabilities">
       <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>
+    <span id="Encryption">
+<p><a href=ols/2002/ols2002-pages-73-92.pdf>The Long Road to the Advanced Encryption Standard</a></p>
+    </span>
   <span id="API (how userspace talks to the kernel)">
     <span id="Syscalls">
@@ -642,11 +670,14 @@
+  <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)
+  <a href=ols/2002/ols2002-pages-183-190.pdf>Porting Drivers to HP ZX1</a>
   <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=>PowerPC implementation reference for QEMU</a>
@@ -655,6 +686,7 @@
   <a href=ols/2001/uml.pdf>User-Mode Linux</a> (OLS 2001)
+  <a href=ols/2002/ols2002-pages-107-116.pdf>Making Linux Safe for Virtual Machines</a> (OLS 2002)
   <a href=ols/2001/x86-64.pdf>Porting Linux to x86-64</a> (OLS 2001)
@@ -681,6 +713,77 @@
   <span id="Releases">
     <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=>expiration of the
+"Don't piss off Larry license"</a> under which BitKeeper was made available
+to the Linux community (<a href=>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=;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=>Linus Torvalds on git</a>.</p>
+<p>To get started with git, see <a href=local/git-quick.html>git quickstart</a>.</p>
+<p>The linux kernel source is also available as a
+<a href=>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=>BitKeeper
+for Kernel Development</a> (OLS 2002, obsolete)</p>
   <span id="community">