login
Search
Yay! The lkml server, vger.kernel.org, is back up and running; we can all get our lkml fix once again ;)
Marcello recently made 2.4.18-rc2 available, bringing us closer to a final version of 2.4.18. This second release candidate had four fixes, as listed in the following changelog...
From: Marcelo Tosatti To: lkml Subject: Linux 2.4.18-rc2 Date: Mon, 18 Feb 2002 18:16:30 -0200 (BRST) We'll hopefully have a 2.4.18 pretty soon.. rc2:
Zack Brown's Kernel Traffic #154 for February 18th is online.
Theo sent out a brief note on the misc OpenBSD mailing list, announcing the release of "a bunch of new snapshots". Of particular need for focus are two driver changes:
A recent thread on the Linux kernel mailing list (lkml) started off by generally bashing Eric S Raymond (ESR). Sifting through the many insults and round trip name calling, though, there was some constructive debating.
The thread was initiated by Jeff Garzik, in response to a message on the kbuild developer's list. The message, from ESR, is a four-point list of suggestions, asking members of the kbuild developer's list to speak with Dirk Hohndel about CML2 and kbuild-2.5, who in turn was to speak with Linus. That thread continues constructively, discussing the pro's and con's of both new systems.
In a recent posting to the lkml, Al Viro announced an up-to-date guide for porting filesystems from the 2.4 stable kernel to the 2.5 development kernel. Unpacking the 2.5.5-pre1 source tree or later (found here), it can be found in the directory 'Documentation/filesystems/porting'. He stressed that it was important to keep this information up to date. It also includes notes on changes that break things.
As detailed in his email, there are two changes currently that break existing file systems: umsdos and intermezo. Al says, "The former will be fixed after the next series of file_system_type cleanups. The latter is a victim of current changes in locking scheme. Help from intermezzo folks would be a good idea - preferably in the form that would reduce the dependency on the VFS guts".
What follows is Al's email, and a snapshot of the following pieces of documentatino from 2.5.5-pre1: porting, directory locking, and Locking.
Recently on the help-hurd mailing list, Ludovic Court
A thread on the lkml started innocently enough about proper spacing in source code, then grew and grew into a somewhat philosophical debate about evolution and code design. The subject of the thread was "Coding style - a non-issue", the general consesus that 'scripts/Lindent' solved the problem, a one line bourne shell script that executes indent with the "proper" options, as defined in the Documentation/CodingStyle document. The script:
indent -kr -i8 -ts8 -sob -l80 -ss -bs -psl "$@"
However, before long a debate was sparked, leading to some interesting comments by Linus and some others, perhaps best summarized by Alan's comment:
"Engineering does not require science. Science helps a lot but people built perfectly good brick walls long before they knew why cement works."
What follows is a reprint of many of the more insteresting posts by some well known Linux kernel hackers:
Robert Love's now-famous preempt Linux Kernel patch has finally been integrated into the main tree. Quoth rml, ""I removed all the sched.h dependencies and this reduced the size of the patch greatly. I now use current_thread_info() and none of the header or include hackery from before. I've tested this with and withot preemption enabled with success."
Browse the linux kernel bitkeeper page for details.
Partha Narayanan, from IBM, recently posted some benchmark perfomance results for Ingo's O(1) Scheduler. The tests were run on an 8-way 700Mhz Pentium III, with several comparisons. These included tests with only one CPU enabled, with 4 CPUs enabled, and with all 8 CPUs enabled. The tests were all on the 2.4.17 kernel, comparisons between the the old scheduler and several revisions of the O(1) scheduler, the latest tested being -J2. (As of this posting, the current revision is -J4)
The end result is around an 18% improvement with a single CPU, around a 45% improvement with 4 CPUs, and around a 187% improvement with 8 CPUs. Pretty impressive!
The benchmark used was the Java based ValanoMark. The raw data follows...
Fans of Ingo Molnar's scheduler patch will be happy to learn that Linus has accepted it into the 2.5 development kernel with 2.5.2-pre10. In releasing his latest update, Ingo comments, "now that Linus has put the -D2 patch into the 2.5.2-pre10 kernel, the 2.5.2-pre10-E1 patch has become quite small :-)".
The -pre10 changelog follows, as does Ingo's E1 changelog.
Ingo Molnar recently posted a patch to the lkml that, in his own words, is "a pretty radical rewrite of the Linux scheduler". He includes links to the patch for 2.5.2-pre6 and 2.4.17. Find the latest versions here. The stated goals are:
His very informative email follows...
A couple of lengthy threads on the lkml drifted away from kernel coding, instead debating the merits of naming standards. The debate was sparked from a patch by David Woodhouse that Eric Raymond applied to Configure.help in the new CML2 configure language. This patch changes references from the familiar MB (megabyte) and GB (gigabyte) to the NIST standard MiB (mebibyte) and GiB (gibibyte). According to these standards, technically a megabyte (MB) is a power of ten, while a mebibyte (MiB) is a power of two, appropriate for binary machines. A megabyte is then 1,000,000 bytes. A mebibyte is the actual 1,048,576 bytes that most intend.
Bits, bytes, kilobytes, megabytes... and now, mebibytes? When one speaks about a kilobyte referring to computer memory, one refers to 1024 bytes. This is more an "accepted innaccuracy" than anything. Though simple enough at the kilobyte level, as memory sizes increase from kilo to mega to giga and beyond, things get more and more confusing. The recent change is an attempt to move away from this "accepted innaccuracy" towards an official and accurate standard.
Some seem to support this change. Others fear it will only add confusion. What do you think?
FreeBSD hacker mailing list, Jordan Hubbard commented on some serious issues with NFS, posting a tool called 'fsx' - originally developed for the NeXT OS - that was ideal for finding them.
