changeset 33:7f23c6db22c2

Incremental progress.
author Rob Landley <rob@landley.net>
date Thu, 06 Sep 2007 17:35:33 -0500
parents 6f30fdd28dab
children 00ba11f14914
files ols/2002/index.html
diffstat 1 files changed, 100 insertions(+), 9 deletions(-) [+]
line wrap: on
line diff
--- a/ols/2002/index.html	Thu Aug 30 17:08:49 2007 -0500
+++ b/ols/2002/index.html	Thu Sep 06 17:35:33 2007 -0500
@@ -151,15 +151,106 @@
 There is <a href=http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=summary>a git version of the contents of the
 old Linux bitkeeper repository</a> online.]</p>
 
-<a href="ols2002_proceedings-pages-213-222.pdf">ols2002_proceedings-pages-213-222.pdf</a><br>
-<a href="ols2002_proceedings-pages-223-241.pdf">ols2002_proceedings-pages-223-241.pdf</a><br>
-<a href="ols2002_proceedings-pages-242-249.pdf">ols2002_proceedings-pages-242-249.pdf</a><br>
-<a href="ols2002_proceedings-pages-250-259.pdf">ols2002_proceedings-pages-250-259.pdf</a><br>
-<a href="ols2002_proceedings-pages-260-264.pdf">ols2002_proceedings-pages-260-264.pdf</a><br>
-<a href="ols2002_proceedings-pages-265-273.pdf">ols2002_proceedings-pages-265-273.pdf</a><br>
-<a href="ols2002_proceedings-pages-274-288.pdf">ols2002_proceedings-pages-274-288.pdf</a><br>
-<a href="ols2002_proceedings-pages-289-300.pdf">ols2002_proceedings-pages-289-300.pdf</a><br>
-<a href="ols2002_proceedings-pages-301-309.pdf">ols2002_proceedings-pages-301-309.pdf</a><br>
+<h2><a href="ols2002_proceedings-pages-213-222.pdf">Linux Advanced Routing &amp; Traffic Control</a> - <b>Bert Hubert</b></h2>
+<p>The "traffic shaper" kernel module can prioritize outgoing network traffic
+according to an elaborate set of rules.  How to use the traffic shaper from
+userspace, and how to write a new scheduler plugin.  [Incomplete in a way that
+assumes you already know the material covered.  For example, it doesn't tell
+you where to download the tools it uses.
+See also the <a href=http://lartc.org/>Linux advanced Routing &amp; Traffice Control HOWTO</a>, a longer and more modern document by the same author.]</p>
+
+<h2><a href="ols2002_proceedings-pages-223-241.pdf">Maintaining the Correctness of the Linux Security Modules Framework</a> - <b>Trent Jaeger, Xiaolan Zhang, Antony Edwards</b></h2>
+<p>The paper observes that "kernel modifications may inadvertently introduce
+security holes", and goes on to discuss how automated regression testing (both
+static and runtime) might prove that an implementation matches a given set of
+design assumptions.  [Unfortunately, it does it in the context of Linux
+Security Modules.  Most of this paper is about LSM, and of no interest outside
+it.  The paper proposed making the non-LSM kernel developers do extra work for
+the benefit of the LSM developers, which didn't happen.  Instead things like
+the stanford checker, sparse, and the Linux Test Project came along to
+test the whole kernel, not just the LSM bits.]</p>
+
+<h2><a href="ols2002_proceedings-pages-242-249.pdf">Buried alive in patches: 6 months of picking up the pieces of the Linux 2.6 kernel</a> - <b>Dave Jones</b></h2>
+<p>During the 2.5 development cycle, Dave Jones forward ported fixes from the
+2.4 stable series to create the 2.5-dj tree.  (This is a role Alan Cox's -ac
+tree had played during the 2.3 cycle.)  What it's like to maintain an
+"integration" kernel tree, the importance of splitting up patches, and
+acceptance and rejection criteria with an eye to merging.  Includes a timeline
+of early 2.5 development.</p>
+
+<p>[Also serves as an excellent summary of what life was like before Linus
+started using source control.  Anybody thinking of maintaining a kernel tree
+should probably read this.]</p>
+
+<h2><a href="ols2002_proceedings-pages-250-259.pdf">Documentation/CodingStyle and Beyond</a> - <b>Greg Kroah-Hartman</b></a></h2>
+<p>Why does the Linux kernel have coding style rules?  (Because a consistent
+style lets other developers understand, review, and revise it more quickly.)
+What are the rules?  (Use tabs to indent, set to 8 characters.  Use K&amp;R
+brace style.  Global variable names are concise, lowercase, use underscores,
+never encode the type in the name, and should be used sparingly.  Local
+variable names are extremely concise (i, j, tmp, etc).  Don't reinvent the
+wheel: functions exist for string handling, byte ordering, and linked lists.
+Also rules for functions, comments, and data structures.  Never use typedef
+except for function (pointer) prototypes.  #define constants for magic numbers.
+How to keep #ifdefs out of C code using tricks like empty inline functions.</p>
+
+<p>[Note: the section on labeled elements in initializers has been superceded,
+Linux now uses the C99 syntax instead of the gcc extension to do this, ala
+struct a b { .c = 123, .d = 456 };]</p>
+
+<h2><a href="ols2002_proceedings-pages-260-264.pdf">An AIO Implementation and its Behavior</a> - <b>Benjamin C. R. LaHaise</b></h2>
+<p>The purpose of Asynchronous I/O is to avoid the collapse of throughput under
+overload conditions often suffered by thrashing multi-threaded network daemons.
+Differences from SigIO, /dev/poll, and /dev/epoll.  The design of AIO, and
+comparison to the Posix AIO spec and NT completion ports.  Testing and
+benchmarks.</p>
+
+<h2><a href="ols2002_proceedings-pages-265-273.pdf">Testing Linux with the Linux Test Project</a> - <b>Paul Larson</b></h2>
+<p>"The Linux Test Project develops test suites that run on multiple platforms
+for validating the reliability, robustness, and stability of the Linux kernel.
+The LTP test suite is designed to be easy to use, portable, and flexible...
+This paper covers what the Linux Test Project is and what we are doing to
+help improve Linux... the features provided by the test harness, the structure
+of the test cases, and how test cases can be written to contribute to the
+Linux Test Project."</p>
+
+<h2><a href="ols2002_proceedings-pages-274-288.pdf">Security Policy Generation through Package Management</a> - <b>Charles Levert, Michel Dagenais</b></h2>
+<p>The paper starts with "Generation and maintenance of security policies is
+too complex and needs simplification for it to be widely adopted..." and goes
+on to propose adding security information to the package management system.
+Mentions work an an RPM-based prototype, but does not provide a link to
+any actual code.</p>
+
+<p>[This paper refers to SELinux but actually seems to be aiming at
+autoconfiguring a project called <a href=http://disec.sourceforge.net/>DSI</a>.
+Creating a set of packages that adhere to the rigid conventions the paper
+suggests would essentially constitute a new Linux distribution, one which
+does not seem to exist.]</p>
+
+<h2><a href="ols2002_proceedings-pages-289-300.pdf">Scalability of the Directory Entry Cache</a> - <b>Hanna Linder, Dipankar Sarma, Maneesh Soni</b></h2>
+<p>Linux caches filesystem metadata in the dentry cache to improve performance,
+but especially on large SMP systems the dentry cache itself can become a
+bottleneck.  The authors optimized the dcache extensively.  This paper covers
+their analysis techniques, the specific problems and solutions, and
+benchmarks of the results.</p>
+
+<p>[Covers not just the dentry cache but general SMP optimization techniques;
+streamlining code, batching, reducing lock contention and cache line bouncing,
+RCU, the importance of benchmarking before attempting to optimize anything,
+etc.]</p>
+
+<h2><a href="ols2002_proceedings-pages-301-309.pdf">BKL: One Lock to Bind Them All</a> - <b>Rick Lindsley, Dave Hansen</b></h2>
+<p>The Big Kernel Lock prevented more than one process from calling into the
+kernel at a time, back when SMP support first went into the 1.3 series.
+Naturally, the scalability of this approach sucked, and adding additional
+locks to improve granularity and reduce lock contention has been a major
+topic ever since.  Where is the Big Kernel Lock still used, how did it come to
+be used that way, and what steps can be taken to remove it?</p>
+
+<p>[A lot of this work has since been done, but if you ever need to break up
+a lock it's good to know how the biggest lock in Linux got broken up.  Plus
+the paper provides an interesting overview of the history of Linux SMP.]</p>
+
 <a href="ols2002_proceedings-pages-310-316.pdf">ols2002_proceedings-pages-310-316.pdf</a><br>
 <a href="ols2002_proceedings-pages-317-329.pdf">ols2002_proceedings-pages-317-329.pdf</a><br>
 <a href="ols2002_proceedings-pages-330-337.pdf">ols2002_proceedings-pages-330-337.pdf</a><br>