“If you push something hard enough, it will fall over; Fudd’s First Law of Opposition” I Think We’re All Bozos On This Bus, Firesign Theatre
Table of Contents
27 September 2022:
This Web publication is in the process of being re-written and updated. About 90% of the exposition from the paper edition has been reworked and presented here from the paper edition. As the authors study the current Linux kernel code for TCP/IP, information referring to old releases of the kernel will be updated and augmented. Additional article sections will be added when they are ready — IPv6 is on this list.
Software, written in Python 3, supports the initial generation and timely updates of commentary Web pages. The code is still in development; a specification has been published for your edification.
The list of commentary sections that will appear in the initial full release include the following topics: IPv4, ICMP, UDP, and TCP.
Once the initial work has been finished, a downloadable ZIP file of the Web publication will be available.
This web publication is the follow-on to the book Linux IP Stacks Commentary. The first edition was published in book form in 2000, by CoriolisOpen™ press, ISBN 1-57610-470-2.
The original edition covered the IP stack in version 2.0.36 of the Linux kernel. Kernel development has progressed much in the subsequent years. The Web edition will cover the TCP/IP stack in Linux kernel 6.0.0 and beyond upon initial full release.
Since his early days on the ARPAnet project in 1972, Stephen T. Satchell has worked with an eclectic variety of information systems and applications. He has contributed over 400 articles to technical magazines (many of them with most-favored co-author H.B.J. Clifford), as well as contributing chapters to a number of books. Mr. Satchell is one of the founding members of the Internet Press Guild (www.netpress.org), a group organized by journalists, pundits, and writers to improve the quality of reporting about the Internet in well-known weekly magazines and other mainstream outlets. Thanks to the efforts of the IPG, reporters around the world now have access to accurate information, and the mailing list serves as Rumor Control.
Writer, editor, and translator H. B. J. Clifford has been active in computer journalism since the mid-1980s. Her work in that field includes stints as a beta-tester and longtime conference moderator on the then-pioneering Byte Information eXchange (BIX) teleconferencing system, technical editor at VLSI Design, associate reviews editor at InfoWorld, contributing editor to Personal Workstation, and editor-in-chief of the quarterly Hewlett-Packard PC Users' Magazine.
In addition to her frequent collaborations with Mr. Satchell, Ms. Clifford has written and/or translated books on database programming, the MIDI music interface, and the Biblical Book of Revelation. Her English translation of an original Brazilian screenplay won critical acclaim at the 1999 Sundance Film Festival. She is also the uncredited co-author of two successful science-fiction adventure novels.
The “Sections” in the Web edition correspond to chapters and appendix topics in the 1st edition. Each section has as its focus a particular topic, like “routing” or “TCP”.
The body text in each section are set in the browser-default serif typeface, and the widths of all figures and tables are sized to fit portable devices such as tablets and smartphones without scrolling.
The sections were prepared using LibreWriter in Linux. (Yes, we eat our own dog food.) The figures were prepared in Dia (a Linux drawing program similar to Microsoft's Visio™), in LibreDraw, and in LibreCalc. Hand-coded HTML was prepared using the Bluefish text editor.
At the beginning of each section described above, is a series of links pointing to reference material, mostly the Request For Comment (RFC) documents used by the Internet community as Standards, referred to within the section.
The commentary design is currently in development. The following paragraphs describe the design concept being considered.
Old: The original edition’s presentation of the source code is prefixed with line numbers in the entire source code corpus. The commentary referenced these line numbers so that the reader could see the correspondence between the code and the comments.
New: The commentary pages are in a two-column format, with the source code in the first column and the comments in the second. The source code and comments appear side by side.
Note: The commentary pages are wider than can be displayed on a smartphone or a tablet without scrolling. Thus, the comment pages are best read on a larger monitor.
Or not. The pages may be built with code and commentary interleaved, just as it has been in some of the textbooks that were written by Stevens and Plauger. The system described in the next few paragraphs could result in either form of display, just by changing the page renderer.
The concept for this system builds on ideas developed by Professor Donald Knuth in his WEB programming system, and CWEB system, to intersperse computer code and natural-language documentation in the same file.
We can’t modify the Linux kernel code, so we have to find a way to couple descriptive text with code located in separate files. In this particular system, the page generator takes a text file of commentary (with markup) and marries that text with the source code by detecting the points of interest in the source code for the text.
Now for the hard part: how to find where to start picking up code for display. Let’s look at some proposed solutions:
Line position: no. The Linux kernel code is undergoing constant revision, with lines of code being added, removed, and modified. That’s as bad as the scheme used for the first edition. The listing had 42,759 printed lines of code, with some lines split to make it fit in the column width.
Tags in source: no. Not only would tagging the source be a huge task, I doubt strongly the Linux community would allow such blasphemous behavior
Logically combine source files: no. In the entire source tree “net”, there are just over 1474 separate files, some of which are not of interest in this book.
Regular expressions within a file: a start. By restricting regular expression searches to individual files, the chances of finding unique patterns grows.
(Paying attention to computer history makes the task easier. Watch…)
First, in whole-language searches , one can use the concept of a word or phrase “near” other words and phrases, to limit the amount of information returned.
Second, the 1970’s UseNet e-mail addressing system used bang paths to describe how to steer through a network manually to the desired node.
So the editorial source code of interest can be identified by a file path and an ordered list of regular expressions. Specifying the filepath is easy. The bang path would describe text searches within the file. For example, we could specify ./net/ipv4/tcp.c for the file, and !^static int tcp_v4_verify_bind(struct sock sk)!!^static __inline int tcp_lport_inuse(int num)! to isolate the tcp_v4_verify_bind function.
As the source code gets updated by the Linux developers, a program can show the code to be extracted for each specification.
The specification for the markup language is here.
Back to Title Page
suggestions, and error reports are welcome.
Send them to:
ipstacks (at) satchell (dot) net
Copyright © 2022 Stephen Satchell, Reno NV USA