diff options
Diffstat (limited to 'en_US.ISO8859-1/htdocs/news/status/report-2003-03-2003-09.xml')
| -rw-r--r-- | en_US.ISO8859-1/htdocs/news/status/report-2003-03-2003-09.xml | 974 |
1 files changed, 974 insertions, 0 deletions
diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2003-03-2003-09.xml b/en_US.ISO8859-1/htdocs/news/status/report-2003-03-2003-09.xml new file mode 100644 index 0000000000..5f20f33720 --- /dev/null +++ b/en_US.ISO8859-1/htdocs/news/status/report-2003-03-2003-09.xml @@ -0,0 +1,974 @@ +<?xml version="1.0" encoding="ISO-8859-1" ?> +<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status Report//EN" + "http://www.FreeBSD.org/XML/www/share/sgml/statusreport.dtd"> + +<!-- $FreeBSD: www/en/news/status/report-2003-03-2003-09.xml,v 1.5 2007/04/11 04:11:09 brd Exp $ --> + +<report> + <date> + <month>March-September</month> + <year>2003</year> + </date> + + <section> + <title>Introduction:</title> + + <p>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.</p> + + <p>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!</p> + + <p>Scott Long, Robert Watson</p> + </section> + +<project> + <title>VideoBSD</title> + + <contact> + <person> + <name> + <given>John-Mark</given> + <common>Gurney</common> + </name> + <email>jmg@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://people.FreeBSD.org/~jmg/videobsd.html">Documentation of + VideoBSD</url> + </links> + + <body> + <p>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.</p> + </body> +</project> + +<project> + <title>KSE</title> + + <contact> + <person> + <name> + <given>Dan</given> + <common>Eischen</common> + </name> + <email>deischen@FreeBSD.org</email> + </person> + + <person> + <name> + <given>David</given> + <common>Xu</common> + </name> + <email>davidxu@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.FreeBSD.org/kse/index.html">KSE Project + Page</url> + </links> + + <body> + <p>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.</p> + + <p>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.</p> + + <p>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.</p> + </body> +</project> + +<project> + <title>FreeBSD/ia64</title> + + <contact> + <person> + <name> + <given>Marcel</given> + <common>Moolenaar</common> + </name> + <email>marcel@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.FreeBSD.org/platforms/ia64/index.html">Project home + page.</url> + </links> + + <body> + <p>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...</p> + <p>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.</p> + <p>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).</p> + <p>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.</p> + <p>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.</p> + </body> +</project> + +<project> + <title>Disk I/O</title> + + <contact> + <person> + <name> + <given>Poul-Henning</given> + <common>Kamp</common> + </name> + <email>phk@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>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.</p> + <p>Once these preliminaries are dealt with, scatter/gather and + mapped/unmapped support will be added to struct bio/GEOM.</p> + </body> +</project> + +<project> + <title>Binary security updates for FreeBSD</title> + + <contact> + <person> + <name> + <given>Colin</given> + <common>Percival</common> + </name> + <email>cperciva@daemonology.net</email> + </person> + </contact> + + <links> + <url href="http://www.daemonology.net/freebsd-update/" /> + </links> + + <body> + <p>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.</p> + + <p>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.</p> + </body> +</project> + +<project> + <title>Porting OpenBSD's pf</title> + + <contact> + <person> + <name> + <given>Max</given> + <common>Laier</common> + </name> + <email>max@love2party.net</email> + </person> + <person> + <name> + <given>Pyun</given> + <common>YongHyeon</common> + </name> + <email>yongari@kt-is.co.kr</email> + </person> + </contact> + + <links> + <url href="http://pf4freebsd.love2party.net"> + http://pf4freebsd.love2party.net</url> + <url href="http://www.benzedrine.cx/pf.html">PF homepage</url> + <url href="http://openbsd.org/faq/pf/index.html">PF FAQ</url> + </links> + + <body> + <p>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.</p> + + <p>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.</p> + + <p>We hope to be eventually integrated into the base system. Before that + we have to resolve some issues with tcpdump and kame.</p> + </body> +</project> + +<project> + <title> + Bluetooth stack for FreeBSD (Netgraph implementation) + </title> + + <contact> + <person> + <name> + <given>Maksim</given> + <common>Yevmenkin</common> + </name> + <email>m_evmenkin@yahoo.com</email> + </person> + </contact> + + <links> + <url href="http://www.geocities.com/m_evmenkin/">Latest snapshot</url> + <url href="http://bluez.sf.net">Linux BlueZ stack</url> + <url href="http://sourceforge.net/projects/openobex/">OpenOBEX</url> + </links> + + <body> + <p>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.</p> + + <p>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.</p> + + <p>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.</p> + + <p>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.</p> + </body> +</project> + + +<project> + <title>Rescue build infrastructure</title> + + <contact> + <person> + <name> + <given>Gordon</given> + <common>Tetlow</common> + </name> + <email>gordon@FreeBSD.org</email> + </person> + + <person> + <name> + <given>Tim</given> + <common>Kientzle</common> + </name> + <email>kientzle@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>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.</p> + </body> +</project> + +<project> + <title>Dynamically Linked Root Support</title> + + <contact> + <person> + <name> + <given>Gordon</given> + <common>Tetlow</common> + </name> + <email>gordon@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>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.</p> + </body> +</project> + +<project> + <title>ACPI Status Report</title> + + <contact> + <person> + <name> + <given>Nate</given> + <common>Lawson</common> + </name> + <email>njl@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.root.org/~nate/freebsd/" /> + </links> + + <body> + <p>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.</p> + + <p>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.</p> + + <p>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.</p> + </body> +</project> + +<project> + <title>uart(4)</title> + + <contact> + <person> + <name> + <given>Marcel</given> + <common>Moolenaar</common> + </name> + <email>marcel@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>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.</p> + <p>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.</p> + <p>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</p> + </body> +</project> + +<project> + <title>Compile FreeBSD with Intels C compiler (icc)</title> + + <contact> + <person> + <name> + <given>Alexander</given> + <common>Leidinger</common> + </name> + <email>netchild@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.Leidinger.net/FreeBSD/">Some patches.</url> + </links> + + <body> + <p>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.</p> + <p>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)</p> + </body> +</project> + +<project> + <title>KDE FreeBSD Project</title> + + <contact> + <person> + <name> + <given>KDE-FreeBSD</given> + <common>Mailinglist</common> + </name> + <email>kde@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://freebsd.kde.org/" /> + </links> + + <body> + <p>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.</p> + + <p>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.</p> + </body> +</project> + + +<project> + <title>WifiBSD Status Report</title> + + <contact> + <person> + <name> + <given>Jon</given> + <common>Disnard</common> + </name> + <email>masta@wifibsd.org</email> + </person> + </contact> + + <links> + <url href="http://www.wifibsd.org">www.wifibsd.org</url> + </links> + + <body> + <p>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.</p> + </body> +</project> + +<project> + <title>PowerPC Port</title> + + <contact> + <person> + <name> + <given>Peter</given> + <common>Grehan</common> + </name> + <email>grehan@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>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.</p> + + <p>There is a huge amount of work to do. Volunteers more than welcome!</p> + </body> +</project> + +<project> + <title>AMD64 Porting</title> + + <contact> + <person> + <name> + <given>Peter</given> + <common>Wemm</common> + </name> + <email>peter@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>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.</p> + + <p>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.</p> + + <p>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.</p> + + </body> +</project> + +<project> + <title>bsd.java.mk version 2.0</title> + <contact> + <person> + <name> + <given>Ernst</given> + <common>De Haan</common> + </name> + <email>znerd@FreeBSD.org</email> + </person> + <person> + <name> + <given>Herve</given> + <common>Quiroz</common> + </name> + <email>herve.quiroz@esil.univ-mrs.fr</email> + </person> + </contact> + <links> + <url href="http://www.esil.univ-mrs.fr/~hquiroz/freebsd/bsd.java.mk-2.0.html">Project homepage</url> + </links> + <body> + <p>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.</p> + <p>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.</p> + </body> +</project> + +<project> + <title>FreeBSD Java Project</title> + + <contact> + <person> + <name> + <given>Greg</given> + <common>Lewis</common> + </name> + <email>glewis@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.FreeBSD.org/java/">FreeBSD Java Project</url> + </links> + + <body> + <p>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.</p> + + <p>The team is continuing development work, with a focus on achieving + a compliant JDK 1.4 release in the near future.</p> + </body> +</project> + +<project> + <title>ATAPI/CAM Status Report</title> + + <contact> + <person> + <name> + <given>Thomas</given> + <common>Quinot</common> + </name> + <email>thomas@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>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.</p> + + </body> +</project> + +<project> + <title>jpman project</title> + + <contact> + <person> + <name> + <given>Kazuo</given> + <common>Horikawa</common> + </name> + + <email>horikawa@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.jp.FreeBSD.org/man-jp/">jpman project</url> + <url href="ftp://daemon.jp.FreeBSD.org/pub/FreeBSD-jp/man-jp/packages-5.1.0/ja-man-doc-5.1.tbz">package ja-man-doc-5.1.tbz</url> + </links> + + <body> + <p>We have released Japanese translation of 5.1-RELEASE online manual + pages on June 10.</p> + </body> +</project> + +<project> + <title>FreeBSD ports monitoring system</title> + + <contact> + <person> + <name> + <given>Mark</given> + <common>Linimon</common> + </name> + <email>linimon_at_lonesome_dot_com</email> + </person> + </contact> + + <links> + <url href="http://lonesome.dyndns.org:4802/bento/errorlogs/index.html"> + FreeBSD ports monitoring system</url> + </links> + + <body> + <p>Several months ago, I took it upon myself to to try present the + information contained on <a href="http://bento.FreeBSD.org">the bento + build cluster</a> 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.</p> + + <p>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 + <a href="http://lonesome.dyndns.org:4802/bento/errorlogs/portoverview.py"> + overview of one port</a>.</p> + </body> +</project> + +<project> + <title>kgi4BSD Status Report</title> + + <contact> + <person> + <name> + <given>Nicholas</given> + <common>Souchu</common> + </name> + <email>nsouch@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.FreeBSD.org/~nsouch/kgi4BSD"> Project URL</url> + </links> + + <body> + <p>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).</p> + + <p>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.</p> + + <p> Volunteers are welcome to the project...</p> + + </body> +</project> + +<project> + <title>Device_t locking</title> + + <contact> + <person> + <name> + <given>Warner</given> + <common>Losh</common> + </name> + <email>imp@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>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.</p> + + </body> +</project> + +<project> + <title>Cryptographic Support</title> + + <contact> + <person> + <name> + <given>Sam</given> + <common>Leffler</common> + </name> + <email>sam@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>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.</p> + + <p>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.</p> + + <p>NetBSD recently imported the cryptographic subsystem.</p> + </body> +</project> + +<project> + <title>Release Engineering Status</title> + + <contact> + <person> + <name> + <given>Scott</given> + <common>Long</common> + </name> + <email>re@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>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.</p> + + <p>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.</p> + + </body> +</project> + +<project> + <title>Wireless Networking Support</title> + + <contact> + <person> + <name> + <given>Sam</given> + <common>Leffler</common> + </name> + <email>sam@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>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.</p> + + </body> +</project> + +<project> + <title>Network Subsystem Locking and Performance</title> + + <contact> + <person> + <name> + <given>Sam</given> + <common>Leffler</common> + </name> + <email>sam@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>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.</p> + + <p>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.</p> + + <p>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.</p> + + </body> +</project> + +</report> |