# HG changeset patch # User Rob Landley # Date 1189118133 18000 # Node ID 7f23c6db22c256baf8627c0a567745bfcdb1554d # Parent 6f30fdd28dab9eb137f96caa804992e0587156c5 Incremental progress. diff -r 6f30fdd28dab -r 7f23c6db22c2 ols/2002/index.html --- 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 git version of the contents of the old Linux bitkeeper repository online.]

-ols2002_proceedings-pages-213-222.pdf
-ols2002_proceedings-pages-223-241.pdf
-ols2002_proceedings-pages-242-249.pdf
-ols2002_proceedings-pages-250-259.pdf
-ols2002_proceedings-pages-260-264.pdf
-ols2002_proceedings-pages-265-273.pdf
-ols2002_proceedings-pages-274-288.pdf
-ols2002_proceedings-pages-289-300.pdf
-ols2002_proceedings-pages-301-309.pdf
+

Linux Advanced Routing & Traffic Control - Bert Hubert

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 Linux advanced Routing & Traffice Control HOWTO, a longer and more modern document by the same author.]

+ +

Maintaining the Correctness of the Linux Security Modules Framework - Trent Jaeger, Xiaolan Zhang, Antony Edwards

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.]

+ +

Buried alive in patches: 6 months of picking up the pieces of the Linux 2.6 kernel - Dave Jones

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.

+ +

[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.]

+ +

Documentation/CodingStyle and Beyond - Greg Kroah-Hartman

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&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.

+ +

[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 };]

+ +

An AIO Implementation and its Behavior - Benjamin C. R. LaHaise

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.

+ +

Testing Linux with the Linux Test Project - Paul Larson

"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."

+ +

Security Policy Generation through Package Management - Charles Levert, Michel Dagenais

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.

+ +

[This paper refers to SELinux but actually seems to be aiming at +autoconfiguring a project called DSI. +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.]

+ +

Scalability of the Directory Entry Cache - Hanna Linder, Dipankar Sarma, Maneesh Soni

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.

+ +

[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.]

+ +

BKL: One Lock to Bind Them All - Rick Lindsley, Dave Hansen

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?

+ +

[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.]

+ ols2002_proceedings-pages-310-316.pdf
ols2002_proceedings-pages-317-329.pdf
ols2002_proceedings-pages-330-337.pdf