diff options
Diffstat (limited to 'en_US.ISO8859-1/htdocs/news/status/report-2001-08.xml')
| -rw-r--r-- | en_US.ISO8859-1/htdocs/news/status/report-2001-08.xml | 1523 |
1 files changed, 1523 insertions, 0 deletions
diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2001-08.xml b/en_US.ISO8859-1/htdocs/news/status/report-2001-08.xml new file mode 100644 index 0000000000..c568aa5dbb --- /dev/null +++ b/en_US.ISO8859-1/htdocs/news/status/report-2001-08.xml @@ -0,0 +1,1523 @@ +<?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-2001-08.xml,v 1.7 2006/08/19 21:20:39 hrs Exp $ --> + +<report> + <date> + <month>August</month> + + <year>2001</year> + </date> + + <cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0"> + <cvs:keyword name="freebsd"> + $FreeBSD: www/en/news/status/report-2001-08.xml,v 1.7 2006/08/19 21:20:39 hrs Exp $ + </cvs:keyword> + </cvs:keywords> + + <section> + <title>Introduction</title> + + <p>The FreeBSD Project made substantial progress in the month of + August, 2001, both on continuing the development of the RELENG_4 + line (4.x-STABLE and 4.x-RELEASE), and on 5.0-CURRENT, the main + development branch. During this month, the decision was made to + push the release of 5.0-CURRENT back so that KSE (support for + fine-grained user threads) could be completed in time for the + release, rather than postponing that support for 6.0. As such, the + lifespan of the RELENG_4 line will be extended, with new features + continuing to be backported to that branch. 4.4-RELEASE went into + final beta during this month, and will also be available + shortly.</p> + + <p>This month's edition of the status report has been written with + the assistance of Nik Clayton and Chris Costello.</p> + </section> + + <section> + <title>Future submissions</title> + + <p>For next month, the submission procedures remain the same: + reports should be between one and two paragraphs long, sent by + e-mail, and in a format approximately that of this month's + submissions (Project, Contact, URL, and text). Reminders will be + mailed to the hackers@FreeBSD.org and developers@FreeBSD.org + mailing lists at least a week before the deadline; complete + submission instructions may be found in those reminders.</p> + + <p>-- Robert Watson</p> + </section> + + <project> + <title>Fibre Channel Support</title> + + <contact> + <person> + <name> + <given>Matthew</given> + + <common>Jacob</common> + </name> + + <email>mjacob@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.feral.com/isp.html" /> + </links> + + <body> + <p>2 Gigabit support was integrated on 8/31/2001 (QLogic + 2300/2312 cards). Because of the author's shrinking time + commitment for FreeBSD, the previously planned "next step" which + would have been more complete new CAM Transport integration is + now probably just the addition of an FC-IP adjunct (as this can + benefit many platforms simultaneously).</p> + </body> + </project> + + <project> + <title>SCSI Tape Support</title> + + <contact> + <person> + <name> + <given>Matthew</given> + + <common>Jacob</common> + </name> + + <email>mjacob@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>A major update to error handling was done on 8/28/2001 which + should correct most of the EOM detection problems that have been + around for a while. There are several things to fix. The + principle thing to fix next is the establishment of a loader(8) + mediated device quirks method.</p> + </body> + </project> + + <project> + <title>CAM</title> + + <contact> + <person> + <name> + <given>Matthew</given> + + <common>Jacob</common> + </name> + + <email>mjacob@FreeBSD.org</email> + </person> + + <person> + <name> + <given>Justin</given> + + <common>Gibbs</common> + </name> + + <email>gibbs@FreeBSD.org</email> + </person> + + <person> + <name> + <given>Kenneth</given> + + <common>Merry</common> + </name> + + <email>ken@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>No change since last status. Some discussion amongst all of us + occurred, but lack of time and commitment to FreeBSD has meant + little has actually been committed to the tree. SMPng work will + be left to those who seem to have a notion about what needs to be + done.</p> + </body> + </project> + + <project> + <title>Intel Gigabit Ethernet</title> + + <contact> + <person> + <name> + <given>Matthew</given> + + <common>Jacob</common> + </name> + + <email>mjacob@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>No new status to report. This driver will be worked on again + soon and cleaned up to work better.</p> + </body> + </project> + + <project> + <title>KSE</title> + + <contact> + <person> + <name> + <given>Julian</given> + + <common>Elischer</common> + </name> + + <email>julian@elischer.org</email> + </person> + + <person> + <name> + <given>Peter</given> + + <common>Wemm</common> + </name> + + <email>peter@FreeBSD.org</email> + </person> + + <person> + <name> + <given>Matt</given> + + <common>Dillon</common> + </name> + + <email>dillon@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>Work in adding supporting infrastructure to the kernel for KSE + threading support has reached "milestone 2".</p> + + <p>Milestone 2 is where the kernel source consistently refers to + its resources in terms of per-thread and per-process resources, + in the way that it will need to when there are > 1 threads per + process, but the LOGICAL changes to such things as the scheduler, + and fork and exit, have not yet been made to allow more than one + thread to be created. (nor have new threading syscalls been added + yet). This is an important milestone as it represents the last + point where the kernel has only "mechanical" changes. To go + further we must start adding new algorithms and functions.</p> + + <p>The kernel for milestone 2 is reliable and has no noticeable + performance degradations when compared to a matching -current + kernel. (the differences are less than the margin of error, so + that sometimes the new kernel actually fractionally beats the + unaltered kernel).</p> + + <p>We hope that by the time this is published, the KSE patches + will have been committed. The Major effect for most developers + will be only that the device driver interface requires a 'thread' + pointer instead of a Proc pointer in the open, close and ioctl + entrypoints.</p> + + <p>I'm sure there will be small teething problems but we are not + expecting great problems at the commit.</p> + </body> + </project> + + <project> + <title>FreeBSD core-secretary</title> + + <contact> + <person> + <name> + <given>Alan</given> + + <common>Clegg</common> + </name> + + <email>abc@FreeBSD.org</email> + </person> + + <person> + <email>core-secretary@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>The position of Core Secretary was filled by Alan Clegg + <abc@FreeBSD.org> The first core-secretary report should be + available the second week in September and will cover the issues + discussed by core during August 2001.</p> + </body> + </project> + + <project> + <title>FreeBSD PAM</title> + + <contact> + <person> + <name> + <given>Mark</given> + + <common>Murray</common> + </name> + + <email>markm@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>Development is continuing; pam_unix has gained the ability to + change passwords, login(1) has had PAM made compulsory (and is + going to have more PAM-capable features handed over to PAM).</p> + </body> + </project> + + <project> + <title>Netgraph ATM</title> + + <contact> + <person> + <name> + <given>Hartmut</given> + + <common>Brandt</common> + </name> + + <email>brandt@fokus.gmd.de</email> + </person> + </contact> + + <body> + <p>The ATM stack has been tested with a number of FreeBSD + machines and a Marconi ATM switch and seems to be quite stable + running CLIP. Multi port support for the native ATM API has been + implemented but needs some testing.</p> + </body> + </project> + + <project> + <title>PRFW - hooks for the FreeBSD kernel</title> + + <contact> + <person> + <name> + <given>Evan</given> + + <common>Sarmiento</common> + </name> + + <email>ems@open-root.org</email> + </person> + </contact> + + <links> + <url href="http://www.freesoftware.fsf.org/jailuser" /> + </links> + + <body> + <p>PRFW is a set of hooks for the FreeBSD kernel. It allows users + to insert code into system calls, for such purposes as creating + extended security features. Last week, PRFW reached 0.1.0, with + many bugfixes and cleaning. I urge anyone who is interested to + please visit the site, join the mailing list. Also take a peek at + lsm.immunix.org, the Linux hooks. It will be a good contrast.</p> + </body> + </project> + + <project> + <title>CVSROOT script rewrite/tidy</title> + + <contact> + <person> + <name> + <given>Josef</given> + + <common>Karthauser</common> + </name> + + <email>joe@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>Work is still progressing to make all of the perl scripts run + using perl's 'strict' mode, and to migrate all FreeBSD specific + options into the configuration file (CVSROOT/cfg.pm). I'll be + looking for help soon to write a guide on how to make use of + these scripts for use in your own repository. Anyone interested + in helping should contact me at the above email address.</p> + </body> + </project> + + <project> + <title>PPP IPv6 Support</title> + + <contact> + <person> + <name> + <given>Brian</given> + + <common>Somers</common> + </name> + + <email>brian@freebsd-services.com</email> + </person> + </contact> + + <body> + <p>The software has been committed to -current and seems + functional. Outstanding issues include dealing with IPV6CP events + (linkup & linkdown scripts) and allocating site-local and + global addresses (currently, ``iface add'' is the only way to + actually use the link).</p> + </body> + </project> + + <project> + <title>Porting ppp to hurd & linux</title> + + <contact> + <person> + <name> + <given>Brian</given> + + <common>Somers</common> + </name> + + <email>brian@freebsd-services.com</email> + </person> + </contact> + + <body> + <p>Status is unchanged since last month. Patches have been + submitted to get ppp working under HURD, and mostly under Linux. + There are GPL copyright problems that need to be addressed. Many + conflicts are expected after the commit of IPv6 support in + ppp.</p> + </body> + </project> + + <project> + <title>pppoed</title> + + <contact> + <person> + <name> + <given>Brian</given> + + <common>Somers</common> + </name> + + <email>brian@freebsd-services.com</email> + </person> + </contact> + + <body> + <p>Making pppoed function in a production environment. All known + problems have been fixed and committed.</p> + </body> + </project> + + <project> + <title>pppoa</title> + + <contact> + <person> + <name> + <given>Brian</given> + + <common>Somers</common> + </name> + + <email>brian@freebsd-services.com</email> + </person> + </contact> + + <body> + <p>I looked at bringing PPPoA into the base system, but could not + because of an overly restrictive distribution license on the + Alcatel Speedtouch modem firmware. It has been committed as a + port instead and is running live at a FreeBSD Services client + site.</p> + </body> + </project> + + <project> + <title>OLDCARD improvements</title> + + <contact> + <person> + <name> + <given>Warner</given> + + <common>Losh</common> + </name> + + <email>imp@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>The OLDCARD improvements have been completed, except for a few + edge cases for older laptops with CL-PD6729/30 chips and some pci + bios issues. Some minor work will continue, but after 4.4R is + released, only a few remaining bugs will be fixed before the + author moves on to greener fields of NEWCARD development.</p> + </body> + </project> + + <project> + <title>jpman project</title> + + <contact> + <person> + <name> + <given>Kazuo</given> + + <common>Horikawa</common> + </name> + + <email>horikawa@psinet.com</email> + </person> + + <person> + <email>man-jp@jp.FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.jp.FreeBSD.org/man-jp/" /> + </links> + + <body> + <p>Targeting 4.4-RELEASE, one team has been translating newly + MFC'ed section [125678] manpages. The other team has been + updating section 3 since May and one third (1/3) is finished. The + port ja-groff is updated to be groff-1.17.2 based, and now it has + the same functionality as base system does. The port ja-man is + updated to have the search capability under an architecture + subdirectory, as base system does. The doc/ja_JP.eucJP/man + hierarchy update (adding architecture subdirectories) is planned + after 4.4-RELEASE.</p> + </body> + </project> + + <project> + <title>ARM port</title> + + <contact> + <person> + <name> + <given>Stephane</given> + + <common>Potvin</common> + </name> + + <email>sepotvin@videotron.ca</email> + </person> + </contact> + + <links> + <url href="http://pages.infinit.net/sepotvin/" /> + </links> + + <body> + <p>Basic footbridge support is now functional and the kernel is + now able to probe the pci bus. Access primitives for the bus are + still missing so I can't attach any drivers yet.</p> + </body> + </project> + + <project> + <title>SYN cache implementation for FreeBSD</title> + + <contact> + <person> + <name> + <given>Jonathan</given> + + <common>Lemon</common> + </name> + + <email>jlemon@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>The syncache implementation is completed, and currently under + testing and review. The code should be committed to -current in + the near future, and a patchset for -stable made available.</p> + </body> + </project> + + <project> + <title>Compressed TCP state</title> + + <contact> + <person> + <name> + <given>Jonathan</given> + + <common>Lemon</common> + </name> + + <email>jlemon@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>State information for TCP connections is primarily kept in the + TCP/IP control blocks in the kernel. Not all of the TCP states + make use of the entire structure, and significant memory savings + can be had by using a cut-down version of the state in some + cases. The first phase of this project will address connections + that are in the TIME_WAIT state by moving them into a smaller + structure.</p> + + <p>This project has completed the initial research and rough + design phases, with actual code development starting + immediately.</p> + </body> + </project> + + <project> + <title>Network SMP locking</title> + + <contact> + <person> + <name> + <given>Jonathan</given> + + <common>Lemon</common> + </name> + + <email>jlemon@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>For 5.0, the goal is for the network stack to run without the + Giant lock. Initial development in this area may focus on + partitioning the code and data structures into distinct areas of + responsibilities. A first pass of locking may involve using a + several smaller mini-giant code locks in order to reduce the + problem to a manageable size.</p> + + <p>Progress for this month includes the creation of a perforce + repository to officially track the locking changes, and the + initial submission of locks for the &ifnet list. Some code + cleanup has also been done to the main tree in order to better + support future locking additions.</p> + </body> + </project> + + <project> + <title>Network device nodes</title> + + <contact> + <person> + <name> + <given>Jonathan</given> + + <common>Lemon</common> + </name> + + <email>jlemon@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>Currently, all network devices (fxp0, lo0, etc) exist in their + own namespace, and are accessed through a socket interface. This + project creates device nodes in /dev for network devices, and + allows control and access in that fashion.</p> + + <p>This is experimental work, and suggestions for APIs and + functionality are strongly encouraged and welcomed. In is not + clear whether it will be possible (or desirable) to provide the + exact same set of operations that can be done through the socket + interface.</p> + + <p>Benefits of approach include the fact that a kqueue filter can + be attached to a network device for monitoring purposes. Initial + code exists to send a kq event whenever the network link status + changes. Other benefits may include better access control by + using filesystem ACLs to control access to the device.</p> + </body> + </project> + + <project> + <title>RELNOTESng</title> + + <contact> + <person> + <name> + <given>Bruce</given> + + <common>Mah</common> + </name> + + <email>bmah@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://people.FreeBSD.org/~bmah/relnotes/" /> + </links> + + <body> + <p>RELNOTESng, the DocBook-ified set of release documentation + files, has been merged to the RELENG_4 branch. 4.4-RELEASE will + be the first release of FreeBSD with the new-style release notes, + hardware list, etc. Some of these documents are being translated + by the Japanese and Russian translation teams.</p> + + <p>Snapshots of RELNOTESng for CURRENT and 4-STABLE in HTML, + text, and PDF are available at the above URL and are updated + irregularly but frequently. Dima Dorfman <dd@FreeBSD.org> + and Nik Clayton <nik@FreeBSD.org> have been working to have + automatically-generated snapshots on the main FreeBSD web + site.</p> + + <p>On my TODO list: 1) Resynchronize the FreeBSD installation + document with the installation chapter in the Handbook. 2) Update + the hardware lists (with particular emphasis on PCCARD and USB + devices). 3) Update the infrastructure to allow the + architecture-dependent parts of RELNOTESng to scale to more + hardware platforms.</p> + </body> + </project> + + <project> + <title>FreeBSD/sparc64 port</title> + + <contact> + <person> + <name> + <given>Jake</given> + + <common>Burkholder</common> + </name> + + <email>jake@FreeBSD.org</email> + </person> + + <person> + <name> + <given>Thomas</given> + + <common>Moestl</common> + </name> + + <email>tmm@FreeBSD.org</email> + </person> + + <person> + <name> + <given>Robert</given> + + <common>Drehmel</common> + </name> + + <email>robert@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>Sparc64 development is still continuing rapidly and we're + making some excellent progress. Of note, some problems with the + way the pmap module implements copy-on-write mappings have been + fixed and fork() now works as expected, support for signals has + been added, and the port has been updated for KSE in the perforce + repository. Thomas Moestl has begun work on pci bus support, and + a basic nexus bus for sparc64 has been written. The driver for + the Sun `Psycho' and `Sabre' UPA-to-PCI bridges and associated + code has been ported from NetBSD (the Sabre is the on-chip + version found in the UltraSparc IIi and IIe). PCI configuration, + I/O and memory space accesses do already work, as well as + interrupt assignment and delivery for devices attached directly + to the bridge, and the first PCI device drivers can attach and + seem to work mostly. Interrupt routing and busdma support still + need much work.</p> + </body> + </project> + + <project> + <title>Documentation Project</title> + + <contact> + <person> + <name> + <given>Nik</given> + + <common>Clayton</common> + </name> + + <email>nik@FreeBSD.org</email> + </person> + + <person> + <name> + <common>Documentation Project</common> + </name> + + <email>doc@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.FreeBSD.org/docs.html" /> + + <url href="http://www.FreeBSD.org/docproj/index.html" /> + </links> + + <body> + <p>The Handbook has been the main focus of activity this month. + Due to go to the printers on the 15th a vast amount of new + content has been submitted and committed. This includes a + complete rewrite of the "Installing FreeBSD", which massively + expands the amount of information available to people new to + FreeBSD. It even includes screenshots.</p> + + <p> + <a + href="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/install.html"> + http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/install.html</a> + </p> + + <p>Comments, and contributions are, of course, welcome.</p> + </body> + </project> + + <project> + <title>IP Multicast Routing support</title> + + <contact> + <person> + <name> + <given>Bill</given> + + <common>Fenner</common> + </name> + + <email>fenner@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>FreeBSD's IP Multicast Routing support was recently updated in + several ways. One big change is that it's now able to be loaded + as a KLD instead of statically compiled into the kernel; this is + especially useful for experimentation or updating of an existing + system. It also now coexists nicely with the kernel IP + encapsulation infrastructure, so that multicast tunnels can + better coexist with MobileIP, certain IPSec tunnels and generic + IPv4-in-IPv4 tunnels.</p> + </body> + </project> + + <project> + <title>Mbuf SMPng allocator</title> + + <contact> + <person> + <name> + <given>Bosko</given> + + <common>Milekic</common> + </name> + + <email>bmilekic@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://people.FreeBSD.org/~bmilekic/code/mb_slab/" /> + </links> + + <body> + <p>The allocator appears to be stable. Mbtypes statistics have + been re-activated thanks, in part, to Jiangyi Liu + <jyliu@163.net> although the diff has not yet been + committed (I'm just in the process of cleaning it up a little and + final testing). More work to come: cleanups, follow TODO from the + original commit, and perhaps an eventual generalization of the + allocator for various network-related allocations (in a more + distant future).</p> + </body> + </project> + + <project> + <title>RAIDframe for FreeBSD</title> + + <contact> + <person> + <name> + <given>Scott</given> + + <common>Long</common> + </name> + + <email>scottl@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://people.FreeBSD.org/~scottl/rf" /> + </links> + + <body> + <p>After two months of little progress, RAIDframe work is gearing + up again. The port to -stable has some known bugs but is fairly + stable. The port to -current was recently completed and patches + will be released soon. RAIDframe is a multi-platform RAID + subsystem designed at CMU. This is a port of the NetBSD version + by Greg Oster.</p> + </body> + </project> + + <project> + <title>aac driver</title> + + <contact> + <person> + <name> + <given>Scott</given> + + <common>Long</common> + </name> + + <email>scottl@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://people.FreeBSD.org/~scottl/aac" /> + </links> + + <body> + <p>The aac driver has been given a lot of attention lately and is + now nearly feature complete. Changes include crashdump support, + correct handling of controller initiated commands, and more + complete management interface support. The Linux RAID management + tool available from Dell and HP now fully works; a FreeBSD native + version of the tool is also in the works. These changes have been + checked into -current, and will appear in -stable once 4.4 has + been released.</p> + </body> + </project> + + <project> + <title>Problem Reports</title> + + <contact> + <person> + <name> + <given>Poul-Henning</given> + + <common>Kamp</common> + </name> + + <email>phk@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://phk.freebsd.dk/Gnats/" /> + </links> + + <body> + <p>We are making some progress, we are now down to 2170 open PR's + down from an all time high of 3270 just 3 months ago. The aim is + still to get rid of all the dead-wood in the PR database so only + relevant PRs in the database. A big thanks from me to the people + who have made this happen!</p> + </body> + </project> + + <project> + <title>network device cloning</title> + + <contact> + <person> + <name> + <given>Brooks</given> + + <common>Davis</common> + </name> + + <email>brooks@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>Support for cloning vlan devices via ifconfig has been + committed to -current and will be MFC'd after further testing. + Additionally, Maksim Yevmenkin submitted code to allow cloning of + tap and vmnet devices on devfs systems. Code for faith and stf + should be committed shortly.</p> + </body> + </project> + + <project> + <title>ia64 Port</title> + + <contact> + <person> + <name> + <given>Doug</given> + + <common>Rabson</common> + </name> + + <email>dfr@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>Current status is that the ia64 kernel builds and runs in a + simulator environment up to single user mode and has been tested + lightly in that environment. My current focus is on completing + the ia64 loader so that I can start to get kernels working on the + real hardware. The loader is coming along well and I expect to be + able to load kernels (but not necessary execute them) soon.</p> + </body> + </project> + + <project> + <title>libh Project</title> + + <contact> + <person> + <name> + <given>Alexander</given> + + <common>Langer</common> + </name> + + <email>alex@FreeBSD.org</email> + </person> + + <person> + <name> + <given>Nathan</given> + + <common>Ahistrom</common> + </name> + + <email>nra@FreeBSd.org</email> + </person> + </contact> + + <body> + <p>I have access to the libh CVS repo again and am testing a new, + OBJDIR capable build structure at the moment. Done that, I'm + going to continue testing the package library and implement the + missing functionality. Currently, import of libh into the base + system is under discussion (arch mailinglist). Now that + 5.0-RELEASE has been shifted, I want 5.0 ship with a libh + installer and package system. We can really need people who are + good in C++, are able to understand what the current + implementation does and also feel that working on libh is fun and + thus are willing to help.</p> + </body> + </project> + + <project> + <title>GNOME Desktop for FreeBSD</title> + + <contact> + <person> + <name> + <given>Maxim</given> + + <common>Sobolev</common> + </name> + + <email>sobomax@FreeBSD.org</email> + </person> + + <person> + <name> + <common>FreeBSD GNOME Team</common> + </name> + + <email>gnome@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>Getting GNOME Fifth-Toe metaport ready for 4.4-RELEASE was the + main focus of activity this month. In the process many components + were updated, many bugs were tracked down and solved, which + allowed to make this 97-component meta-package building and + working properly.</p> + + <p>Next month the project will be focused on organizing work of + the FreeBSD GNOME Team as well as on attempts to increase amount + of people participating in the team (anybody who is willing to + participate is welcome to drop a note to gnome@FreeBSD with a + short explanation of how he/she could help).</p> + </body> + </project> + + <project> + <title>fbsd-nvdriver</title> + + <contact> + <person> + <name> + <given>Erik</given> + + <common>Greenwald</common> + </name> + + <email>erik@floatingmind.com</email> + </person> + + <person> + <name> + <given>Joel</given> + + <common>Willson</common> + </name> + + <email>siigorny@linuxsveeden.borkborkbork</email> + </person> + </contact> + + <links> + <url href="http://fbsd-nvdriver.sourceforge.net" /> + </links> + + <body> + <p>NVIDIA Corporation releases Linux drivers by using a + combination of binary object files and source (under a + constrictive license). The FreeBSD NVIDIA driver project aimed to + completely replace the source component of the driver using code + targeting FreeBSD 4.3 and released under the BSD license. The + binary module provided is supposedly the same module used on + Windows, BeOS, and OS/2, so it should be portable between + different i80x86 based OS's.</p> + + <p>The project is currently on indefinite hold. Our contact at + NVIDIA seemed enthusiastic about the project, and was fairly + quick about returning email, but when we discovered issues that + prevented porting without changes to the binary component or + error codes we needed deciphered, Nick (the contact) said he'd + look into it and never got back. The first major problem was the + ioctl interface, the NVIDIA driver passes a pointer and depends + on the kernel side to copyout the right amount, where FreeBSD + expect the parameters to be correct and the copyout is performed + by the subsystem. This was worked around using Dave Rufinos + "ioctl tunnel" idea. After that, we found that X refused to load + and traced it down to an ioctl defined in the binary component + erroring. We cannot tell what that ioctl is, were told that we + could not sign an NDA for source to that component, and have been + waiting a month for Nick to "look into it". Therefore progress is + impossible (without breaking the license) and we believe that the + flaws make the driver unportable to any *nix other than + Linux.</p> + </body> + </project> + + <project> + <title>FreeBSD Release Engineering</title> + + <contact> + <person> + <name> + <common>FreeBSD Release Engineer Team</common> + </name> + + <email>re@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>The FreeBSD release engineering process for FreeBSD 4.4 + started to ramp up around August 1st when the "code slush" took + affect. During this time all commits to the RELENG_4 branch were + reviewed by re@FreeBSD.org (over 250 code snippets had to be + reviewed). After the first release candidate on August 15th, all + submissions were scrutinized under a more strict potential risk + vs benefit curve. The best way to help get involved with the + release engineering process is to simply follow the low volume + freebsd-qa mailing list, help out with the neverending supply of + PRs related to our installation tools (sysinstall), or to work on + a possible next-generation replacement for our installation + technology, such as the libh or OpenPackages projects.</p> + + <p>Many companies donated equipment, network access, or paychecks + to finance these activities. Including Compaq, Yahoo!, Wind River + Systems, and many more.</p> + </body> + </project> + + <project> + <title>Improved TCP Initial Sequence Numbers</title> + + <contact> + <person> + <name> + <given>Mike</given> + + <common>Silbersack</common> + </name> + + <email>silby@silby.com</email> + </person> + </contact> + + <body> + <p>In mid March, 2001, Tim Newsham of Guardent identified an + attack possible against the initial sequence number generation + scheme of FreeBSD (and other OSes.) In order to guard against + this threat, a randomized sequence number generation scheme was + ported over from OpenBSD and included in 4.3-release. + Unfortunately, non-monotonic generation was found to cause major + problems with applications which initiate continuous, rapid + connections to a single host.</p> + + <p>In order to restore proper operation under such circumstances + while still providing strong resistance against sequence number + prediction, FreeBSD 4.4 uses the algorithm specified in RFC 1948. + This algorithm hashes together host and port information with a + piece of secret data to generate a unique sequence number space + for each connection. As a result, outgoing initial sequence + numbers are again monotonic, but also unguessable by an + attacker.</p> + </body> + </project> + + <project> + <title>LOMAC</title> + + <contact> + <person> + <name> + <given>Brian</given> + + <common>Feldman</common> + </name> + + <email>green@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>The port of LOMAC to FreeBSD is progressing well, and already + has a very high level of stability (no known outstanding bugs!). + Aspects which have already been implemented include a stacking + filesystem overlay with fully-functional access controls (for + files and directories) based on path names, access controls for + sending signals, and file-backed-memory revocation for + processes.</p> + </body> + </project> + + <project> + <title>SMPng</title> + + <contact> + <person> + <name> + <given>John</given> + + <common>Baldwin</common> + </name> + + <email>jhb@FreeBSD.org</email> + </person> + + <person> + <name> + <given>Peter</given> + + <common>Wemm</common> + </name> + + <email>wemm@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.FreeBSD.org/~jasone/smp/" /> + </links> + + <body> + <p>Updates to things from last month: + <ul> + <li>The ast() fixes were committed last month.</li> + + <li>The work on the preemptive kernel is stalled for the time + being. It is still unstable on Alpha and SMP systems.</li> + </ul> + </p> + + <p>New stuff since last month: + <ul> + <li>sx locks now support upgrades and downgrades.</li> + + <li>Witness now supports lock upgrades and downgrades.</li> + + <li>Jason Evans has committed a semaphore implementation.</li> + + <li>Matt Dillon has pushed Giant down into all of the + syscalls.</li> + + <li>John Baldwin has been working on proc locking in a p4 + 'jhb_proc' branch.</li> + + <li>John is also currently working on making the ktrace code + use a work thread to asynchronously write trace data out to the + trace file. This will make ktrace safe almost completely MP + safe with the exception that a few ktrace events need Giant in + order to call malloc(9) and that ktrgenio() is still + synchronous. Specifically, however, ktrpsig(), ktrsysret(), and + ktrcsw() no longer need Giant.</li> + + <li>Jonathan Lemon has started work on locking the network + stack in a p4 'netlock' branch.</li> + </ul> + </p> + </body> + </project> + + <project> + <title>FreeBSD Java Project</title> + + <contact> + <person> + <name> + <given>Greg</given> + + <common>Lewis</common> + </name> + + <email>glewis@eyesbeyond.com</email> + </person> + </contact> + + <links> + <url href="http://www.FreeBSD.org/java/" /> + </links> + + <body> + <p>Most of the work this month has focused on development of the + native JDK 1.3.1 patchset. The 3rd patchset is out and has been + accompanied with the creation of a FreeBSD "port". This has + allowed early adopters much easier access to the code and + naturally resulted in a number of bugs being found. Development + work has mostly focused on fixing these problems and the project + is now set to release fourth patchset over the weekend, which + should see the JDK in a reasonably usable state. One of the big + challenges left is producing a working HotSpot JVM, which looks + like it will require some heavy hacking.</p> + + <p>We also welcome OpenBSD's Heikki Korpela to the porting team + :)</p> + </body> + </project> + + <project> + <title>floppy driver overhaul</title> + + <contact> + <person> + <name> + <given>Joerg</given> + + <common>Wunsch</common> + </name> + + <email>j@uriah.heep.sax.de</email> + </person> + </contact> + + <body> + <p>As part of some ongoing development activity, the floppy + driver (fdc(4)) enjoyed some overhaul in the past which is part + of an ongoing process. Automatic density selection will come + next, something i meant to implement for years now. As part of + that, the entire density selection stuff has been rewritten. 2.88 + MB floppies are on the wishlist as well, but I need a working + 2.88 drive before attempting to implement that.</p> + </body> + </project> + + <project> + <title>sppp(4) merge</title> + + <contact> + <person> + <name> + <given>Joerg</given> + + <common>Wunsch</common> + </name> + + <email>j@uriah.heep.sax.de</email> + </person> + </contact> + + <body> + <p>sppp(4) should be merged with the ISDN4BSD offspring variant. + This will merge some features and bugfixes from the i4b branch + (like VJ compression), and eventually end up in a single sppp(4) + in the tree. While being at that, incorporating many changes and + bugfixes from NetBSD is considered as well.</p> + </body> + </project> + + <project> + <title>KAME</title> + + <contact> + <person> + <name> + <given>Munechika</given> + + <common>Sumikawa</common> + </name> + + <email>sumikawa@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.kame.net/" /> + </links> + + <body> + <p>The KAME project (http://www.kame.net/) has merged its IPv6 + and IPsec implementation as of July 2001 to FreeBSD CURRENT and + STABLE, in cooperation with some contributors of the project. The + latest code includes a number of bug fixes, has been fully tested + in FreeBSD STABLE, and will appear in FreeBSD 4.4 RELEASE. Thus, + the new RELEASE version will be quite stable in terms of IPv6 and + IPsec.</p> + + <p>The project has assigned a talented guy to be responsible for + merge from KAME to FreeBSD, so future merge efforts will be + smoother.</p> + </body> + </project> + + <project> + <title>TrustedBSD</title> + + <contact> + <person> + <name> + <given>Robert</given> + + <common>Watson</common> + </name> + + <email>rwatson@FreeBSD.org</email> + </person> + + <person> + <email>trustedbsd-discuss@TrustedBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.TrustedBSD.org/" /> + </links> + + <body> + <p>The TrustedBSD project continues to move ahead, with progress + made in the ACL, Capability, and MAC implementations. In + addition, support from DARPA is permitting new work to improve + the extended attribute code, improve security abstractions, and + work on security documentation. Due to the push-back of the + FreeBSD 5.0 release, it should now be possible to include a + complete MAC implementation in that release. Specific status + reports appear for components where substantial progress is being + made.</p> + </body> + </project> + + <project> + <title>TrustedBSD Capabilities</title> + + <contact> + <person> + <name> + <given>Robert</given> + + <common>Watson</common> + </name> + + <email>rwatson@FreeBSD.org</email> + </person> + + <person> + <name> + <given>Thomas</given> + + <common>Moestl</common> + </name> + + <email>tmm@FreeBSD.org</email> + </person> + + <person> + <email>trustedbsd-discuss@TrustedBSD.org</email> + </person> + </contact> + + <body> + <p>Capabilities support is currently being committed to the base + FreeBSD tree--userland libraries are now fully committed, and + kernel infrastructure is being integrated.</p> + </body> + </project> + + <project> + <title>BSDCon Europe</title> + + <contact> + <person> + <name> + <given>Paul</given> + + <common>Richards</common> + </name> + + <email>paul@freebsd-services.com</email> + </person> + </contact> + + <body> + <p>Planning for BSDCon Europe is going well. We're still + accepting proposals for talks but the schedule is starting to + fill up so we may not be for much longer.</p> + + <p>An update of the site that includes accommodation information, + a preliminary schedule, a list of speakers and an online payment + page will be launched on Wednesday 19 September.</p> + + <p>The fee will be £150 for individuals and £250 for + corporations. The individual pricing is valid only until the end + of September, the price will rise to £200 for October and + late registrations in November will be £250.</p> + + <p>The updated website will include a list of sponsorship + options, we're still looking for more sponsorship.</p> + </body> + </project> +</report> |