Introduction:

diff --git a/en/news/status/Makefile b/en/news/status/Makefile index 9500fab0bd..f6f61f46d3 100644 --- a/en/news/status/Makefile +++ b/en/news/status/Makefile @@ -1,41 +1,42 @@ -# $FreeBSD: www/en/news/status/Makefile,v 1.19 2003/01/24 04:11:01 scottl Exp $ +# $FreeBSD: www/en/news/status/Makefile,v 1.20 2003/03/15 10:00:08 scottl Exp $ .if exists(../Makefile.conf) .include "../Makefile.conf" .endif .if exists(../Makefile.inc) .include "../Makefile.inc" .endif .SUFFIXES: .xml .html DOCS= status.sgml DATA= report-june-2001.html DATA+= report-july-2001.html DATA+= report-august-2001.html DATA+= report-september-2001.html DATA+= report-november-2001.html DATA+= report-dec-2001-jan-2002.html DATA+= report-feb-2002-apr-2002.html DATA+= report-may-2002-june-2002.html DATA+= report-july-2002-aug-2002.html DATA+= report-sept-2002-oct-2002.html DATA+= report-nov-2002-dec-2002.html DATA+= report-jan-2003-feb-2003.html +DATA+= report-mar-2003-sep-2003.html # Install a sample entry. DATA+= report-sample.xml CLEANFILES+= ${DATA:M*.html} .xml.html: report.xsl includes.xsl ${XSLTPROC} ${XSLTPROCOPTS} -o ${.TARGET} \ ${.CURDIR}/report.xsl ${.IMPSRC} .if !defined(NO_TIDY) -${TIDY} ${TIDYOPTS} ${.TARGET} .endif INDEXLINK= status.html .include "${WEB_PREFIX}/share/mk/web.site.mk" diff --git a/en/news/status/report-2003-03-2003-09.xml b/en/news/status/report-2003-03-2003-09.xml new file mode 100644 index 0000000000..6e5d8f7df2 --- /dev/null +++ b/en/news/status/report-2003-03-2003-09.xml @@ -0,0 +1,970 @@ + + + + + March-September + 2003 + + +

+ 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

+ + + VideoBSD + + + + + John-Mark + Gurney + + jmg@FreeBSD.org + + + + + Documentation of + VideoBSD + + + +

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.

+ + + + + KSE + + + + + Dan + Eischen + + deischen@FreeBSD.org + + + + + David + Xu + + davidxu@FreeBSD.org + + + + + KSE Project + Page + + + +

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.

+ + + + + FreeBSD/ia64 + + + + + Marcel + Moolenaar + + marcel@FreeBSD.org + + + + + Project home + page. + + + +

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.

+ + + + + Disk I/O + + + + + 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.

+ + + + + Binary security updates for FreeBSD + + + + + 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.

+ + + + + Porting OpenBSD's pf + + + + + Max + Laier + + max@love2party.net + + + + Pyun + YongHyeon + + yongari@kt-is.co.kr + + + + + + http://pf4freebsd.love2party.net + PF homepage + PF FAQ + + + +

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.

+ + + + + + Bluetooth stack for FreeBSD (Netgraph implementation) + + + + + + Maksim + Yevmenkin + + m_evmenkin@yahoo.com + + + + + Latest snapshot + Linux BlueZ stack + OpenOBEX + + + +

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.

+ + + + + + Rescue build infrastructure + + + + + Gordon + Tetlow + + gordon@FreeBSD.org + + + + + 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.

+ + + + + Dynamically Linked Root Support + + + + + 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.

+ + + + + ACPI Status Report + + + + + 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.

+ + + + + uart(4) + + + + + 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

+ + + + + Compile FreeBSD with Intels C compiler (icc) + + + + + Alexander + Leidinger + + netchild@FreeBSD.org + + + + + Some patches. + + + +

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)

+ + + + + KDE FreeBSD Project + + + + + 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.

+ + + + + + WifiBSD Status Report + + + + + Jon + Disnard + + masta@wifibsd.org + + + + + www.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.

+ + + + + PowerPC Port + + + + + 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!

+ + + + + AMD64 Porting + + + + + 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.

+ + + + + + bsd.java.mk version 2.0 + + + + Ernst + De Haan + + znerd@FreeBSD.org + + + + Herve + Quiroz + + herve.quiroz@esil.univ-mrs.fr + + + + Project homepage + + +

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.

+ + + + + FreeBSD Java Project + + + + + Greg + Lewis + + glewis@FreeBSD.org + + + + + FreeBSD Java Project + + + +

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.

+ + + + + ATAPI/CAM Status Report + + + + + 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.

+ + + + + + jpman project + + + + + Kazuo + Horikawa + + + horikawa@FreeBSD.org + + + + + jpman project + package ja-man-doc-5.1.tbz + + + +

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

+ + + + + FreeBSD ports monitoring system + + + + + Mark + Linimon + + linimon_at_lonesome_dot_com + + + + + + FreeBSD ports monitoring system + + + +

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.

+ + + + + kgi4BSD Status Report + + + + + Nicholas + Souchu + + nsouch@FreeBSD.org + + + + + Project URL + + + +

A lot of work done since last report: site reworked completly (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.

+ +

Volonteers are welcome to the project...

+ + + + + + Device_t locking + + + + + 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.

+ + + + + + Cryptographic Support + + + + + 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.

+ + + + + Release Engineering Status + + + + + 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.

+ + + + + + Wireless Networking Support + + + + + 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.

+ + + + + + Network Subsystem Locking and Performance + + + + + 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.

+ + + + + diff --git a/en/news/status/report-mar-2003-sep-2003.xml b/en/news/status/report-mar-2003-sep-2003.xml new file mode 100644 index 0000000000..6e5d8f7df2 --- /dev/null +++ b/en/news/status/report-mar-2003-sep-2003.xml @@ -0,0 +1,970 @@ + + + + + March-September + 2003 + + +