diff options
Diffstat (limited to 'en/news/status/report-2003-03-2003-09.xml')
| -rw-r--r-- | en/news/status/report-2003-03-2003-09.xml | 970 |
1 files changed, 0 insertions, 970 deletions
diff --git a/en/news/status/report-2003-03-2003-09.xml b/en/news/status/report-2003-03-2003-09.xml deleted file mode 100644 index cf42d8744f..0000000000 --- a/en/news/status/report-2003-03-2003-09.xml +++ /dev/null @@ -1,970 +0,0 @@ -<!-- $FreeBSD: www/en/news/status/report-mar-2003-sep-2003.xml,v 1.2 2004/04/04 21:46:14 phantom 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 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).</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> Volonteers 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> |