login
Search
The question was asked recently on a FreeBSD mailing list, "What will be new in FreeBSD 5.0?" The thread discussed several ways a person could obtain such information, one good source being the latest release notes. The first developer preview of 5.0 was released on April 8th [earlier story]. The final release is targeted for the end of this year.
Robert Watson offered an interesting summary of items to look forward to in FreeBSD 5.0, including: SMPng ("next generation" symmetric multiprocessing), KSE (improved scheduling), devfs (automatic /dev management), Firewire support, and much more. Read on for more details.
When Linus made his switch to BitKeeper for maintaining the kernel source tree, the format of his changelogs also changed. Linus himself at one point commented that simplifying the changelog was on his todo list, however many spoke out in support of the newer, more verbose logs. They have since been the standard. Find an example of the old style here, and the new style here.
The question of readability came up on the lkml recently, Ian Molton saying, "I dont know who to write to about this, but the changelogs for 2.4.19-pre on kernel.org are COMPLETELY illegible." He went on to suggest that the logs be tweaked a little. Linus agreed that the logs could be improved, and put out a call to Perl scripters to help with the change. Some of the discussion follows, as well as a link to the thread in online archives.
Robert Millan recently made available an image [link temporarily removed] allowing a person to run the GNU/Hurd under the Bochs x86 emulator [earlier story about Bochs]. With very minimal effort, I launched the GNU/Hurd image with Bochs v0.4 and was then able to use the Hurd from within my Linux server. [screenshot]
As Bochs compiles on many platforms, this even allows non-x86 users to run the Hurd. Of course, the emulation is slow...
Update: (5/13/2) The link to the Hurd image for Bochs has been removed at this time. This was done at Robert's request, as the images are a work in progress, and not yet fully stable. Once ready, the image should be found here.
Story resurrected from old site archives by request:
Ever since interviewing Robert Love last October, I've added his preemptible kernel patch to all my running kernels, with great results. Ingo Molnar's recent O(1) scheduler has also looked attractive, but I've been waiting until it was compatible with Robert's patch before trying it. The wait is over.
This afternoon Robert announced the release of a O(1) scheduler compatible preemptible kernel patch for the stable 2.4 kernel tree and the 2.5 development kernel. He says,
"Getting the two to play together was not hard, albeit a bit of a pain. The actually scheduling support is less, due to the simplified schedule and schedule_tail, although there is added code for making the per-CPU runqueues preempt-safe."
What follows is Robert's announcement email, as well as Ingo's announcement of his -H6 version of the O(1) scheduler.
Peter Chubb posted a patch to the lkml, with which he's now managed to mount a 15 terabyte file (using JFS and the loopback device). Without the patch, Peter explains, "Linux is limited to 2TB filesystems even on 64-bit systems, because there are various places where the block offset on disc are assigned to unsigned or int 32-bit variables."
Peter works on the Gelato project in Australia. His efforts include cleaning up Linux's large filesystem support, removing 32-bit filesystem limitations. When I asked him about the new 64-bit filesystem limits, he offered a comprehensive answer and this interesting link. The full thread follows.
Reaching beyond terabytes, beyond petabytes, on into exabytes. I feel this sudden discontent with my meager 60 gigabyte hard drive...
Following some interesting scheduler benchmarking [earlier story], a discussion of the results has continued on the lkml. Though the O(1) scheduler offered impressive boosts in most cases, it was noticed that pipe latency increased, and pipe bandwidth decreased [earlier story].
Mike Kravitz suggested, "I believe the decrease in pipe bandwidth is a direct result of the removal of the '__wake_up_sync' support," then asking what the purpose behind this code was in the first place. Andrea Arcangeli explained that the code was an optimization for SMP servers to put processes sharing a pipe on the same CPU if they exceed the alloted buffers. (A full pipe will cause one process to block the other) The tests offered in this thread show that when multiple processes can block the other, keeping them on the same CPU offers a significant gain in bandwidth.
The decision was made to remove Perl from the FreeBSD -current base system [earlier story]. Perl will be supported as a port that the user can install after the base installation, however it will no longer be required.
Mark Murray put out a call to the -current mailing list asking for volunteers to port all Perl scripts in the base system to another language, such as sh or C. All critical programs are already being ported, with only a few minor ones left to be claimed.
Michael Smith recently posted his resignation from the FreeBSD core team. His resignation came shortly after the resignation of one of the FreeBSD founder's, Jordan Hubbard [earlier story]. Michael echoed similiar sentiments, with the project no longer being fun for him, "instead [it having] become obsessed with process and mechanics."
On the FreeBSD home page you can find a historical list of core team members, a list of the current core members, and a list of contributors who have commit privileges to the FreeBSD source tree.
Keith Owens released v2.0 of kuild 2.5 on April 5, boasting a 30% speed improvement over kbuild 2.4 thanks to a rewrite of the core code [earlier story]. He announced that kbuild 2.5 was ready for kernel inclusion May 1 [earlier story], and a debate followed [earlier story]. There has still been no public word from Linus as to when kbuild 2.5 will be merged into the mainline 2.5 development kernel.
Much of the debate is surrounding Keith's choices for "getting it right". In his own words, "kbuild 2.4 defaults to doing a (possibly) inaccurate build after changes," whereas "kbuild 2.5 defaults to always doing an accurate build, no matter what has changed." With the rise of more and more kernel patches, Keith points out that more and more people are going to need the benifits of kbuild 2.5. He concludes, "the default for kernel build must be a safe and accurate build."
kbuild 2.5 is currently at revision 2.4, available here.
Robert Love recently posted a patch (developed by MontaVista) to the lkml bringing the preemptible kernel patch to the MIPS architecture.
Jeremy adds: Robert continues to keep the preempt patch up-to-date with the latest 2.4 kernel and the latest 2.4 -ac patch. His latest patches can be found here
Mark Murray recently started a thread on the "current" FreeBSD mailing list regarding "the future of Perl on FreeBSD". He says, "The recent removal of the CGI perl module from CURRENT started a very lively discussion on both the perl lists and some FreeBSD ones." The Perl community's complaint is that Perl should be included fully or not at all. The complaints against Perl include it's increasing size and the fact that FreeBSD as an OS makes little use of Perl.
Three possible solutions were suggested: 1) leave Perl in the base and deal with it. 2) split Perl into two pieces, base and libraries. 3) remove Perl and make it a port which a user can add as s/he wishes.
Most responses endorsed the third option, though there is work in making this possible. Matthew Dillon pointed out several core programs that use Perl, suggesting as a workaround adding a 'miniperl' to be included in base that these programs could point to, but that would not conflict in any way with the Perl port.
Randy Hron posted some additional O(1) scheduler benchmarks [earlier story], this time illustrating how the scheduler patch seems to decrease pipe bandwidth and increase pipe latency. (neither affect is good)
The thread goes on to talk about Davide Libenzi's Balanced Multi Queue Scheduler patch (BMQS). Andrea Arcangeli says of this scheduler (which he has in his -aa kernel tree), "Davide's patch reduces the complexity of the scheduler from O(N) where N is the number of tasks in the system, to O(N) where N is the number of simultaneous running tasks in the system. It's also a simple optimization and it can make responsiveness even better than the mainline scheduler."
The third scheduler mentioned is the MQ, or Linux MultiQue Scheduler. The Linux Showcase & Conference web site offers an informative comparison of the Default SMP Scheduler (DSS), the MultiQueue Scheduler (MQS), and the Pooled MultiQueue Scheduler (PMQS).
Users of OpenBSD 2.9-STABLE are advised that this code branch will no longer be maintained starting June 1st, 2002. Miod Vallat says, "After this day, there will be NO MORE fixes commited to this branch. People relying on 2.9-STABLE are strongly advised to upgrade to a more recent release (preferrably 3.1 as it becomes available) as soon as possible.".
The next stable release, OpenBSD 3.1, is due in about two weeks, around May 19th. [earlier story]
Josef Karthauser recently posted to the current FreeBSD mailing list, describing the status of recent USB stack changes. He explains, "The background is that I've been porting the developments that NetBSD has had into FreeBSD. In some cases we were two years behind the state of the art. Today we're in a much better shape."
Recently there have been some complaints to bugs in the updated USB stack, some people going so far as recommending the whole change be backed out. Josef's email was a comprehensive update on the project, listing three remaining bugs to be fixed:
Looking ahead to after these problems are resolved, Josef says, "The good news is that once these issues have been resolved we are in a good position to port the drivers that NetBSD have but we've not seen yet. There are lots, like uaudio and uvisor, that we should take avantage of."
With Keith Owens' announcement that kbuild 2.5 is ready for inclusion into the 2.5 development tree, a discussion on the lkml followed. The big complaint was based on Keith Owens decision to not support modversions (versioned symbols) with this release. Martin Dalecki compared the Linux design process to the Solaris design process, the latter intended to illustrate a better method. Alan Cox explained:
"Now I don't actually give a hoot whether you implement the module binding via /proc/kernel.so and C++ like mangling hacks or the _R stuff we do now but don't confuse the Linux approach of putting a few million users before a few binary module ISV's with the Solaris one."
Kai Germaschewski in turn complained about Keith's style of making such a large change and breaking modversions. Keith explains:
"I have been waiting for somebody to raise the "why not do one bit a time" argument for kbuild. That is exactly what I have done! Modversions are completely broken but are not required for a development kernel, they will be done later. There are 89 'FIXME' comments in the Makefile.in files where changes to source code should be done to clean up the include mess, those changes will be done later."
For full details, read on...
