Skip site navigation (1) Skip section navigation (2)

Introduction:

The FreeBSD Bi-monthly status reports are back! In this edition, we catch up on seven highly productive months and look forward to the end of 2003.

As always, the FreeBSD development crew has been hard at work. Support for the AMD64 platform quickly sprang up and is nearly complete. KSE has improved greatly since the 5.1 release and will soon become the default threading package in FreeBSD. Many other projects are in the works to improve performance, enhance the user experience, and expand FreeBSD into new areas. Take a look below at the impressive summary of work!

Scott Long, Robert Watson

Bluetooth stack for FreeBSD (Netgraph implementation)

URL: http://www.geocities.com/m_evmenkin/
URL: http://bluez.sf.net
URL: http://sourceforge.net/projects/openobex/

Contact: Maksim Yevmenkin <m_evmenkin@yahoo.com>

I'm very pleased to announce that another release is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030908.tar.gz. I have also prepared patch for the FreeBSD source tree. The patch was submitted for review to the committers.

Fixed few bugs in kernel modules. The ng_hci(4) and ng_l2cap(4) modules were changed to fix issue with Netgraph timeouts. The ng_ubt(4) module was changed to fix compilation issue on -current.

Improved user-space utilities. Implemented new libsdp(3). Added new sdpcontrol(8) utility. The rfcomm_sppd(1), rfcomm_pppd(8) and obexapp(1) were changed and now can obtain RFCOMM channel via SDP from the server. The hccontorol(8) utility now has four new commands. The hcsecd(8) daemon now saves link keys on the disk.

I've been recently contacted by few individuals who whould like to port current FreeBSD Bluetooth code to other BSD systems (OpenBSD and NetBSD). The work is slowly progressing towards un-Netgraph'ing current code. In the mean time Netgraph version will be the primary supported version of the code.

ACPI Status Report

URL: http://www.root.org/~nate/freebsd/

Contact: Nate Lawson <njl@FreeBSD.org>

Work is continuing on updating ACPI with new features as well as bugfixing. A new embedded controller driver was written in July with support for the ACPI 2.0 ECDT as well as more robust polling support. Also, a buffer overflow in the ACPICA resource list handling that caused panics for some users was fixed. Marcel helped get acpidump(8) tested and basically working on ia64.

Upcoming work includes integrating ACPI notifies with devd(8), committing user-submitted drivers for ASUS and Toshiba hotkeys, Cx processor sleep states (so my laptop doesn't burn my lap), and power resource support for intelligently powering down unused or idle devices.

Users who have problems with ACPI are encouraged to submit a PR and email its number to acpi-jp@jp.FreeBSD.org. Bug reports of panics or crashes have first priority and non-working features or missing devices (except suspend/resume problems) second. Reports of failed suspend/resume should NOT be submitted as PRs at this time due to most of them being a result of incomplete device support that is being addressed. However, feel free to mail them to the list as any information is helpful.

AMD64 Porting

Contact: Peter Wemm <peter@FreeBSD.org>

The last known bug that prevented AMD64 machines completing a full release has been fixed - one single character error that caused ghostscript to crash during rendering diagrams. SMP work is nearing completion and should be committed within the next few days. The SMP code uses the ACPI MADT table based on John Baldwin's work-in-progress there for i386. We need to spend some time on low level optimization because there are several suboptimal places that have been ignored for simplicity, context switching in particular. MTRR support has been committed and XFree86 can use it. cvsup now works but the ezm3 port has not been updated yet. The default data segment size limit is 8GB instead of 512M, and the (primitive) i386 binary emulation support knows how to lower the rlimits for executing 32 bit binaries.

Notable things missing still: Hardware debug register support needs to be written; gdb is still being done as an external set of patches relative to the not-yet-released FSF gdb tree; DDB does not disassemble properly; DDB cannot do stack traces without -fno-omit-frame-pointer - a stack unwinder is needed; i386 and amd64 linux binary emulation is needed, and the i386 FreeBSD binary emulation still needs work - removing the stackgap code in particular.

The platform in general is very reliable although a couple of problems have been reported over the last week. One appears to be a stuck interrupt, but all that code has been redone for SMP support.

ATAPI/CAM Status Report

Contact: Thomas Quinot <thomas@FreeBSD.org>

With the introduction of ATAng, some users of ATAPI/CAM have experienced various problems. These have been mostly tracked down to issues in the new ATA code, as well as two long-standing problems in portions of the CAM layer that are rarely exercised with "real" SCSI SIMs. This has also been an occasion to cleanup ATAPI/CAM to make it more robust, and to enable DMA for devices accessed through it, resulting in improved performances.

Binary security updates for FreeBSD

URL: http://www.daemonology.net/freebsd-update/

Contact: Colin Percival <cperciva@daemonology.net>

FreeBSD Update is a system for tracking the FreeBSD release (security) branches. In addition to being faster and more convenient than source updates, FreeBSD Update also requires less bandwidth and is more secure than source updates via CVSup. However, FreeBSD Update is limited; it can only update files which were installed from an official RELEASE image and not recompiled locally. Right now I'm publishing binary updates for 4.7-RELEASE and 4.8-RELEASE; since my only available box takes 3.5 hours to buildworld, I don't have enough resources to do any more than that.

In the near future, I'd like to: Find someone who is willing to donate a faster buildbox; start building updates for other releases (at a minimum, for all "supported" FreeBSD releases); add warnings if a file would have been updated but can't be updated because it was recompiled locally; add code to compare the local system against a list of "valid" MD5 hashes for intrusion detection purposes; and add support for cross-signing, whereby several machines could build updates independently to protect against buildbox compromise.

bsd.java.mk version 2.0

URL: http://www.esil.univ-mrs.fr/~hquiroz/freebsd/bsd.java.mk-2.0.html

Contact: Ernst De Haan <znerd@FreeBSD.org>
Contact: Herve Quiroz <herve.quiroz@esil.univ-mrs.fr>

The FreeBSD Java community has started an effort to improve the current framework for Java-based ports. The main objective is the automation of JDK/JRE build and run dependency checking.

The original version was aimed to ease the life of porters. Although it has proved to be useful and reliable to a great extend, we are currently working on a new version. We intend to reach a high degree of flexibility to cope with the recent increase of available JDK/JRE flavors. Furthermore, the new version will be easier to maintain, which means improved reliability, and hopefully more frequent updates.

Compile FreeBSD with Intels C compiler (icc)

URL: http://www.Leidinger.net/FreeBSD/

Contact: Alexander Leidinger <netchild@FreeBSD.org>

Since I ported icc to FreeBSD I wanted to build FreeBSD with icc. Now with icc 7.1 (and some patches) it is possible. There are still some bugs, e.g. NFS doesn't work with an icc compiled kernel, IP seems to be fragile, and some advanced optimizations trigger an ICE (Intel is working on it). At the moment I'm waiting for our admins to install icc on the FreeBSD cluster (we got a commercial license from Intel, so we are allowed to distribute binaries which are compiled with icc), after that I will try to convince some people with more knowledge of the IP and NFS parts of the kernel to debug the remaining problems. When the icc compiled kernel seems to work mostly bugfree the userland will get the porting focus. Interested people may try to do a build of the ports tree with icc independently from the status of the porting of the userland... if this happens at the FreeBSD cluster, we would also be allowed to distribute the binaries.

Benefits include: another set of compiler errors (debugging help), more portable source, and code which is better optimized for a P4 (gcc has some drawbacks in this area)

Cryptographic Support

Contact: Sam Leffler <sam@FreeBSD.org>

Support for several new crypto devices was added. The SafeNet 1141 is a medium performance part that is not yet available on retail products. The Hifn 7955 and 7956 parts are starting to appear on retail products that should be available by the end of the year. Both devices support AES encryption. Support for public key operations for the SafeNet devices was recently done for OpenBSD and will be backported. Public key support for the Hifn parts is planned.

A paper about the performance work done on the cryptographic subsystem was presented at the Usenix BSDCon 2003 conference and received the best paper award.

NetBSD recently imported the cryptographic subsystem.

Device_t locking

Contact: Warner Losh <imp@FreeBSD.org>

A number of races have been identified in locking device_t. Most of the races have been identified in making device_t have to do with how drivers are written. Efforts are underway to identify all the races, and to contact the authors of subsystems that can help the drivers. Of special concern is the need for the driver to ensure that all threads are completely out of the driver code before detach() finishes. Of additional concern is making sure that all sleepers are woken up before certain routines are called so that other subsystems can ensure the last condition and leave no dangling references. Locking device_t is relatively straight forward apart from these issues. Towards the end of proper locking, sample strawmen drivers are being used to work out what, exactly proper is. Once these issues are all known and documented in the code, efforts will be made to update relevant documentation in the tree. There are many problems with driver locking that has been done to date, but until we nail down how to write a driver in current, it will be premature to contact specific driver writers with specific concerns.

Disk I/O

Contact: Poul-Henning Kamp <phk@FreeBSD.org>

The following items are in progress in the Disk I/O area: Turn scsi_cd.c into a GEOM driver. (Patch out for review). Turn atapi-cd.c into a GEOM driver. Turn fd.c into a GEOM driver. Move softupdates and snapshot processing from SPECFS to UFS/FFS. Move userland access to device drivers out of vnodes.

Once these preliminaries are dealt with, scatter/gather and mapped/unmapped support will be added to struct bio/GEOM.

Dynamically Linked Root Support

Contact: Gordon Tetlow <gordon@FreeBSD.org>

Support for a dynamically linked /bin and /sbin has been committed, although it is not turned on by default. Adventurous users can try it out by building /bin and /sbin using the WITH_DYNAMICROOT make flag. More testing is needed to determine if this is going to be default for 5.2-RELEASE. If anyone would like to benchmark worldstones with and without dynamically linked /bin and /sbin, please feel free to do so and submit the results.

FreeBSD Java Project

URL: http://www.FreeBSD.org/java/

Contact: Greg Lewis <glewis@FreeBSD.org>

The BSD Java Porting Team has recently reached an exciting milestone with the release of the first "Diablo" JDK and JRE courtesy of the FreeBSD Foundation. The release of Diablo Caffe and Diablo Latte 1.3.1 was the first binary release of a native FreeBSD JDK since 1.1.8 and marks an important step forward in FreeBSD Java support.

The team is continuing development work, with a focus on achieving a compliant JDK 1.4 release in the near future.

FreeBSD ports monitoring system

URL: http://lonesome.dyndns.org:4802/bento/errorlogs/index.html

Contact: Mark Linimon <linimon_at_lonesome_dot_com>

Several months ago, I took it upon myself to to try present the information contained on the bento build cluster to be presented in a more user-friendly fashion; that is, to be browsed by error type, by maintainer, and so forth. An early addition was code to attempt to classify ports PRs by either "existing port" (after assiging the most likely category and portname); "new port"; "framework" (e.g. bsd.port.mk changes); and "unknown". Various columns about the ports PRs were added to the reports.

The initial intent of this was to make life easier for ports maintainers; however, the "general" reports are also useful to anyone who just wants to, e.g., find out if a particular port is working on their particular architecture and OS combination before downloading it. Those with that general interest should start with the overview of one port.

FreeBSD/ia64

URL: http://www.FreeBSD.org/platforms/ia64/index.html

Contact: Marcel Moolenaar <marcel@FreeBSD.org>

Much has happened since the last bi-monthly report, which was more than half a year ago. FreeBSD 5.0 and FreeBSD 5.1 have been released for example. With FreeBSD 5.2 approaching quickly, we're not going to look back too far when it comes to our achievements. There's too much ahead of us...

Two milestones have been reached after FreeBSD 5.1. The first is the ability to support both Intel and HP machines with sources in CVS. This due to a whole new driver for serial ports, or UARTs. Unfortunately this still implies that syscons is not configured. That's another task for another time, but keep an eye on KGI/FreeBSD... The second milestone is the completion of KSE support. Both M:N and 1:1 threading is functional on ia64 and the old libc_r library has been obsoleted. Testing has shown that KSE (i.e. M:N) may well become the default threading model. It's looking good.

The ABI hasn't changed after 5.1 and the expectation is that it won't change much. This means that we can think about becoming a tier 1 platform. This also means we need gdb(1) support. Work on it has been started but the road is bumpy and long. Kernel stability also has improved significantly and we typically have one kernel panic remaining: VM fault on no fault entry. This will be addressed with the long awaited PMAP overhaul (see below).

Most work for FreeBSD 5.2 will be "sharpening the saw". Get those loose ends tied. This is a slight change of plan made possible by a slip in the release schedule. The 5.2 release is not going to be the start of the -stable branch; it has been moved to 5.3. So, we use the extra time to prepare the ground for 5.3.

The planned PMAP overhaul will probably be finished after 5.2. This should address all known issues with SMP and fix those last panics. As a side-effect, major performance improvements can be expected. More news about this in the next status reports.

jpman project

URL: http://www.jp.FreeBSD.org/man-jp/
URL: ftp://daemon.jp.FreeBSD.org/pub/FreeBSD-jp/man-jp/packages-5.1.0/ja-man-doc-5.1.tbz

Contact: Kazuo Horikawa <horikawa@FreeBSD.org>

We have released Japanese translation of 5.1-RELEASE online manual pages on June 10.

KDE FreeBSD Project

URL: http://freebsd.kde.org/

Contact: KDE-FreeBSD Mailinglist <kde@FreeBSD.org>

The FreeBSD ports were updated to KDE 3.1.4, another bug- and security-fixes release. With this update, the QT port was updated to version 3.2. Both will be included in FreeBSD 4.9. Significant work was spent to fix KDE on FreeBSD-CURRENT after the removal of the gcc -pthread Option. Automatic package builds from KDE CVS continued to ensure and improve the quality of the upcoming KDE 3.2 release.

Future: Work is in progress to setup a new server for hosting the KDE-FreeBSD Website, Repository and another KDE CVS mirror. With help from Marcel Moolenaar the project will try to make KDE compile and working on the Intel IA64. And last but not least efforts are being made to fix the currently broken kdesu program.

kgi4BSD Status Report

URL: http://www.FreeBSD.org/~nsouch/kgi4BSD

Contact: Nicholas Souchu <nsouch@FreeBSD.org>

A lot of work done since last report: site reworked completely (see new URL), console design with console message in text or graphic modes implemented, implementation of a compatibility layer to compile Linux fbdev drivers with more or less changes in the original driver (experimental).

Except some memory allocation bugs, X (XGGI based on XFree 3.3.6) is now working with the same driver as the console. A basic terminal has now to be implemented.

Volunteers are welcome to the project...

KSE

Contact: Dan Eischen <deischen@FreeBSD.org>
Contact: David Xu <davidxu@FreeBSD.org>

KSE seems to be working well on x86, amd64, and ia64. The alpha userland bits are done, but a couple of functions are unimplemented in the kernel. For sparc64, the necessary functions are implemented in the kernel, but the userland context switching functions need more attention.

Since 5.1, efficient scope system threads (no upcalls when they block) have been implemented, and KSE based pthread library can have both POSIX scope process threads and scope system threads. It is also possible that KSE based pthread library can implement pthread both in 1:1 and M:N mode, I know Dan has such Makefile file patch for libkse not yet committed.

KSE program now can work under ULE scheduler, its efficient should be improved under the new scheduler in future. BSD scheduler is still the best scheduler for current KSE implement.

Network Subsystem Locking and Performance

Contact: Sam Leffler <sam@FreeBSD.org>

The purpose of this project is to improve performance of the network subsystem. A major part of this work is to complete the locking of the networking subsystem so that it no longer depends on the "Giant lock" for proper operation. Removing the use of Giant will improve performance and permit multiple instances of the network stack to operate concurrently on multiprocessor systems.

This project started in August. The emphasis has been on locking the "lower half" of the networking code so that packet forwarding through the IPv4 path can operate without the Giant lock as part of the 5.2 release. To this end locking was added to several network interface drivers and much of the "middleware" code in the network was locked (e.g. ipfw, dummynet, then routing table, multicast routing support, etc). Work towards this goal is still ongoing but should be ready for 5.2. A variety of test systems have been running for several months without the Giant lock in the network drivers and IP layer.

Past the 5.2 release Giant will be removed from the "upper half" of the network subsystem and the socket layer. Once this is done the plan is to measure and improve performance (though some work of this sort is always happening). The ultimate goal is a system that performs at least as well as 4.x for normal use on uniprocessor systems. On multiprocessor systems we expect to see significantly better performance than 4.x due to greater concurrency and reduced latency.

Porting OpenBSD's pf

URL: http://pf4freebsd.love2party.net
URL: http://www.benzedrine.cx/pf.html
URL: http://openbsd.org/faq/pf/index.html

Contact: Max Laier <max@love2party.net>
Contact: Pyun YongHyeon <yongari@kt-is.co.kr>

The project started this spring and released version 1.0 with a port installation (security/pf) in may 2003. Version 2.0 is on the doorstep as OpenBSD 3.4 will be released. Due to the porting efforts we were able to reveal some bugs in the OpenBSD code and provided locking for the PFIL_HOOKS, which we utilize. Tarball installation of a loadable kernel module for testing can be found on the project homepage, a patchset is in the making.

PF was started at OpenBSD as a substitute for ipfilter and provides the same function set. However, in the two years it exists now, it has gained many superior features that no other packet filter has. For a impression take a look at the pf FAQ.

We hope to be eventually integrated into the base system. Before that we have to resolve some issues with tcpdump and kame.

PowerPC Port

Contact: Peter Grehan <grehan@FreeBSD.org>

Work has restarted after a hiatus. Current focus is on getting loadable modules working, NEWBUSing the NetBSD dbdma code, and completing the BMAC ethernet driver.

There is a huge amount of work to do. Volunteers more than welcome!

Release Engineering Status

Contact: Scott Long <re@FreeBSD.org>

The release of 4.9 is just around the corner and offers Physical Address Extensions (PAE) for x86 along with the same world-class stability and performance that is expected from the 4-STABLE series. As always, don't forget to purchase a copy of the CD set from your favorite FreeBSD vendor.

FreeBSD 5.1 was released in June and offered vastly improved stability over 5.0 along with a working implementation of Kernel Scheduled Entities, allowing for true multithreading of applications across multiple CPUs. FreeBSD 5.2 will be released by the end of 2003 and will focus on improved network and overall performance.

Rescue build infrastructure

Contact: Gordon Tetlow <gordon@FreeBSD.org>
Contact: Tim Kientzle <kientzle@FreeBSD.org>

The rescue build infrastructure has been committed. There is one known issue with make using both the '-s' and '-j' flags that appears to be a bug in make. Anyone interested in tracking down should contact us.

uart(4)

Contact: Marcel Moolenaar <marcel@FreeBSD.org>

The uart(4) project was born out of the need to have a working serial interface (i.e. an RS-232-C interface) in a legacy-free configuration and after an unsuccessful attempt to convert sio(4). The biggest problem with sio(4) is that it has been intertwined in many ugly ways into the kernel's core. Conversion could not happen without breaking something that invariably affects some group of people negatively. With sio(4) as a good bad example and a strong desire to solve multiple problems at once, the idea of an UART (Universal Asynchronuous Receiver/Transmitter) device that, given its generic name, could handle different flavors of UART hardware started to settle firmly in the authors mind.

The biggest challenge was of course solving the problem of the low-level console access prior to the initialization of the bus infrastructure and still have a driver that uses the bus access exclusively. Along the way the problem of having an UART function as the keyboard on sparc64 was solved with the introduction of system devices, which also encapsulated the console as a system device.

The uart(4) driver can be enhanced to support the various UART hardware on pc98 and this is currently being worked on. Keyboard support on sparc64 is underway as well. Plans exist for a rewrite of the remote gdb support that uses a generic interface to allow various drivers, including uart(4), to register itself as a communications channel. And since uart(4) does not support multi- port cards by itself, we likely need to either enhance puc(4) or otherwise introduce other umbrella drivers

VideoBSD

URL: http://people.FreeBSD.org/~jmg/videobsd.html

Contact: John-Mark Gurney <jmg@FreeBSD.org>

Still in the planning stage. Working on creating an extensible interface that is usable for both userland and kernel implementations for device drivers. Deciding on how to interface userland implemented device drivers with applications.

WifiBSD Status Report

URL: http://www.wifibsd.org

Contact: Jon Disnard <masta@wifibsd.org>

WifiBSD is a miniture version of FreeBSD for wireless applications. Originally for the Soekris Net45xx line of main-boards, but is now capable of being targeted to any hardware/architecture FreeBSD itself supports. Although not feature complete, WifiBSD is expected to be ready for 5.2-RELEASE. The design goal is to meet, or exceed, the functionality of commercial/consumer 802.11 wireless gear. Features that need attention (to name just a few) are: http interface, consol menu interface, and installation. Volunters are welcome.

Wireless Networking Support

Contact: Sam Leffler <sam@FreeBSD.org>

Numerous bugs have been fixed since the last status report (and of course a few new ones added). Progress on improved security has been slowed by other work. But new features and fixes are coming in from other groups that are now sharing the code. In particular NetBSD recently imported the revised 802.11 layer and the Linux-based MADWIFI project is using it too (albeit in an older form). The MADWIFI users have already contributed features such as fragmentation reassembly of 802.11 frames and improved signal monitoring. Power save polling and an improved rate control algorothm are expected to come in from the NetBSD folks. WPA support is still in the plans; the best estimate is that work on that will start in January.

News Home | Status Home