diff --git a/en/news/status/Makefile b/en/news/status/Makefile index 5591ac17f6..b5a93662a7 100644 --- a/en/news/status/Makefile +++ b/en/news/status/Makefile @@ -1,39 +1,40 @@ -# $FreeBSD: www/en/news/status/Makefile,v 1.17 2002/10/03 19:17:15 rwatson Exp $ +# $FreeBSD: www/en/news/status/Makefile,v 1.18 2002/11/25 22:41:56 scottl Exp $ .if exists(../Makefile.conf) .include "../Makefile.conf" .endif .if exists(../Makefile.inc) .include "../Makefile.inc" .endif .SUFFIXES: .xml .html DOCS= status.sgml DATA= report-june-2001.html DATA+= report-july-2001.html DATA+= report-august-2001.html DATA+= report-september-2001.html DATA+= report-november-2001.html DATA+= report-dec-2001-jan-2002.html DATA+= report-feb-2002-apr-2002.html DATA+= report-may-2002-june-2002.html DATA+= report-july-2002-aug-2002.html DATA+= report-sept-2002-oct-2002.html +DATA+= report-nov-2002-dec-2002.html # Install a sample entry. DATA+= report-sample.xml CLEANFILES+= ${DATA:M*.html} .xml.html: report.xsl includes.xsl ${XSLTPROC} ${XSLTPROCOPTS} -o ${.TARGET} \ ${.CURDIR}/report.xsl ${.IMPSRC} .if !defined(NO_TIDY) -${TIDY} ${TIDYOPTS} ${.TARGET} .endif INDEXLINK= status.html .include "${WEB_PREFIX}/share/mk/web.site.mk" diff --git a/en/news/status/report-2002-11-2002-12.xml b/en/news/status/report-2002-11-2002-12.xml new file mode 100644 index 0000000000..43a9b5d27c --- /dev/null +++ b/en/news/status/report-2002-11-2002-12.xml @@ -0,0 +1,875 @@ + + + November-December + 2002 + + +
+ Introduction: + +

At long last, FreeBSD 5.0 is here. Along with putting the final + polish on the tree, FreeBSD developers somehow found the time to + work on other things too. IA64 took some major steps towards + working on the Itanium2 platform, an effort was started to + convert all drivers to use busdma and ban vtophys(), hardware + crypto support and DEVD hit the tree, NewReno was fixed and + effort began on locking down the network layer of the kernel. + Also high performance, modular scheduler started taking shape + and will be a welcome addition to the kernel soon.

+ +

Looking forward, the focus will be on stabilizing and + improving the performance of 5.0. The RELENG_5 (aka 5-STABLE) + branch will be created once we've reached our goals in this + area, so hopefully we will get there quickly. Meanwhile, + preparations for the next release from the 4.x series, 4.8, + will begin soon. Of course, the best way to get 5.x to + stabilize os to install and run it!

+ +

Thanks,

+ +

Scott Long, Robert Watson

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

I'm very pleased to announce that all kernel modules and few userland + tools made it to the FreeBSD source tree. Many thanks to Julian + Elischer.

+ +

Unfortunately no big changes since the last report. Some minor problems + have been discovered and patches are available on request. I will prepare + all the patches and submit them to Julian for review.

+ +

OBEX server and client (based on OpenOBEX library) is almost complete. + I'm currently doing interoperability testing. If anyone has hardware and + time please contact me. The HCI security daemon has been implemented and + tested with Sony Ericsson T68i cell phone and Windows stack. It is now + possible to setup secure Bluetooth connections.

+ +

A few people have complained about RFCOMM daemon. These individuals want + to use GPRS and Bluetooth enabled cell phone to access Internet. If you + have this problem please contact me for possible workaround. My next goal + is to get robust RFCOMM implementation to address all these issues.

+ + + + + TrustedBSD Project: Access Control Lists + + + + + Robert + + Watson + + + rwatson@FreeBSD.org + + + + TrustedBSD Discussion List + + + trustedbsd-discuss@TrustedBSD.org + + + + + TrustedBSD Project + + + +

Largely bug-fixing and userland application tweaks; new + interfaces were added to manipulate ACLs on extended attributes; + bugs were fixed in ls relating to ACL flagging. Patches to + teach cp, mv, gzip, bzip, and other apps about ACL preservation + are in testing and review. tunefs flags were added to ease + configuration of ACLs, especially on UFS2 file systems.

+

Possible changes to make use of Linux/Solaris umask semantics + are under consideration: right now we implement verbatim + POSIX.1e/IRIX merging of the umask, ACL mask, and requested + creation mode during file, device, fifo, and directory creation. + Solaris and the most recent Linux patches ignore the umask in + the context of a default ACL; this requires some rearrangement + of umask handling in our VFS, although the results would be + quite useful. We're exploring how to do this in a low impact + way.

+ + + + + TrustedBSD Project: MAC Framework + + + + + Robert + + Watson + + + rwatson@FreeBSD.org + + + + TrustedBSD Discussion List + + + trustedbsd-discuss@TrustedBSD.org + + + + + TrustedBSD Project + + + +

Framework changes:

+

Instrument KLD system calls (module and kld load, unload, stat) + Instrument NFSd system call. Instrument swapoff(2). + Instrument per-architecture privileged parts of sysarch(). + Make use of condition variables to allow callers to wait for the + framework to "unbusy" when loading/unloading policies, rather than + returning EBUSY. Store mount pointer in devfs_mount structure for + use by policies. Improve handling of labels in loopback interface + "re-align" packet copy case. Provide full paths on devfs object + creations to help policies label them properly (not merged). + Experimentation with moving MAC labels into m_tags (not merged). + NFS server now uses real ucreds, not hacked up ucreds, + meaning we can start laying the groundwork for enforcement on + NFS operations. (not merged)

+ +

Policy changes

+

LOMAC: mac_lomac replaces lomac (LOMAC now uses the MAC Framework), + SEBSD: Improved support for devfs labeling based on SELinux genfs. + Handling of hard link checks. Support export of process transition + information for login and others using sysctl. Login now prompts + for roles. Allow policy reload. TTY labeling. Locking adaptation + from Linux. Many, many policy adaptations and fixes. We can + now boot in enforcing mode! mac_bsdextended: fix a bug in which + VAPPEND wasn't mapped to VWRITE, so opens with the O_APPEND bug + failed improperly.

+ +

Userland changes

+

setfmac(8) now supports a setfsmac(8) execution mode, which accepts + initial labeling specification files. Supports an SELinux compatibility + mode so it can accept SELinux label specfiles using the SEBSD module. + sendmail(8) now sets user labels as part of the context switch for mail + delivery.

+ +

Documentation changes

+

Man page updates for MAC command line tools, modules, admin hints, etc. + Updates to the FreeBSD Developer's Handbook chapter on MAC policies + and entry points. MAC section in FreeBSD Handbook.

+ + + + + busdma driver conversion project + + + + + Maxime + + Henrion + + + mux@FreeBSD.org + + + + + + + + +

This project has been coming along pretty well. The amd(4) and + xl(4) drivers have now been converted to use the busdma API, + sparc64 got the bus_dmamap_load_mbuf() and bus_dmamap_load_uio() + functions, and the gem(4) and hme(4) drivers have been updated + to use bus_dmamap_load_mbuf() instead of bus_dmamap_load().

+ +

A lot more still needs to be done, as shown on the project's + page. A fair number of conversions are on their way though, + and we can expect a fair number of drivers to be converted + soon, thanks to all the developers who are working on this + project.

+ + + + + FreeBSD C99 & POSIX Conformance Project + + + + + Mike + Barcroft + + + mike@FreeBSD.org + + + + FreeBSD-Standards Mailing List + + + standards@FreeBSD.org + + + + + + + + + +

The POSIX Utility Conformance in FreeBSD list (link above) has + been updated to reflect current reality. Not much work remains + to complete base utility conformance.

+ +

On the API front, grantpt(), posix_openpt(), unlockpt(), + wordexp(), and wordfree() were implemented. The header + <wordexp.h> was added.

+ +

There are currently about 40 unassigned tasks on our project's + status board ranging from documentation, utilities, to kernel + hacking. We would encourage any developers looking for something + to work on to check out the status board and see if anything + interests them.

+ + + + + Hardware Crypto Support Status + + + + + Sam + Leffler + + + sam@FreeBSD.org + + + + +

The goal of this project is to import the OpenBSD kernel-level crypto + subsystem. This facility provides kernel- and user-level access to + hardware crypto devices for the calculation of cryptographic hashes, + ciphers, and public key operations. The main clients of this facility + are the kernel RNG (/dev/random), network protocols (e.g. IPsec), and + OpenSSL (through the /dev/crypto device).

+ +

This work will be part of the 5.0 release and has been committed to + the -stable source tree for inclusion in the 4.8 release.

+ +

Recent work has focused on improving performance. System statistics are + now maintained and an optional profiling facility was added for + analyzing performance. Using this facility the overhead for using the + crypto API has been significantly reduced.

+ +

The ubsec (Broadcom) driver was changed to significantly improve + performance under load. In addition several memory leaks were fixed in + the driver and the public key support was enabled for use.

+ +

Upcoming work will focus on load-balancing requests across multiple + crypto devices and integrating OpenSSL 0.9.7 which will automatically + enable application use of crypto hardware.

+ + + + + DEVD + + + + + Warner + Losh + + + imp@FreeBSD.org + + + + +

Devd has been integrated into FreeBSD 5.0-RELEASE. The + integrated code supports a range of configuration options. The + config files are fully parsed now and their actions are + performed.

+ +

Future work in this area are likely to be limited to imporving + the devctl interface. /dev/devctl likely will be a cloneable + device in future versions. Individual device control via devctl + is also planned.

+ + + + + Donations Team Status Report + + + + + Michael + Lucas + + + donations@FreeBSD.org + + + + + Donations main page + FreeBSD + developer wantlist + + completed donations + + + +

The Donations project expedited several dozen donations during + 2002, and was able to place most of what was offered. We still + are in dire need of SMP and Sparc systems. You can see + information on our needs and donations that have been handled by + the team on the donations web page.

+ +

We are relying increasingly upon the developer wantlist to + place items offered to the Project, and using the commit + statistics to help place items. As such, active committers who + ask for what they want beforehand have a decent chance of + getting it. Less active committers, and committers who do not + ask for what they want, will be lower in our priorities but will + not be excluded.

+ +

We are in the process of streamlining the tax deduction process + for donations, and hope to have news on that shortly. We are + also always working to accelerate and reduce our internal + processes, to get the most equipment in the hands of the most + people as quickly as possible.

+ +

I especially want to thank David O'Brien and Tom Rhodes for + stepping up and making the team far more successful. Also, the + FreeBSD Foundation has been quite helpful in handling + tax-deductible contributions.

+ + + + + + + Fast IPsec Status + + + + + Sam + Leffler + + + sam@FreeBSD.org + + + + +

The main goal of this project is to modify the IPsec protocols to use + the kernel-level crypto subsystem imported from OpenBSD (see elsewhere). + A secondary goal is to do general performance tuning of the IPsec + protocols.

+ +

This work will be part of the 5.0 release. Performance has been improved + due to work on the crypto subsystem.

+ + + + + FFS volume label support + + + + + Gordon + Tetlow + + + gordon@FreeBSD.org + + + + + Current patch set. + + + +

The goal of the project is to use a small amount of space in the FFS + superblock to store a volume label of the user's choice. A GEOM module + will then expose the volume labels into a namespace in devfs. The idea + is to make it easier to manage filesystems across disk swaps and + movement from system to system.

+ +

At this point, everything pretty much works. I've submitted parts of + the patch to respective subsystem maintainers for review. There are some + issues with namespace collision that I haven't addressed yet, but the + basic functionality is there

+ + + + + French FreeBSD Documentation Project + + + + Sebastien + Gioria + + + gioria@FreeBSD.org + + + + Marc + Fonvieille + + blackend@FreeBSD.org + + + + Stéphane + Legrand + + stephane@FreeBSD.ORG + + + + + The French FreeBSD Documentation Project. + The FreeBSD Web Server translated in French. + Translation of the hanbook. + French Daemon News like web site. + + + +

Most of the articles are translated too. Marc is still translating the + handbook, 60% is currently translated. Stéphane has began the + integration of our French localization web site in the US CVS Tree. + Sébastien is still maintaining the Release Notes.

+ +

We launched a new site, www.FreeBSD-fr.info, consisting in a French + Dameon News like site. Netasq have donated our new server; we will + install it in a new hosting provider in the few next weeks. One of the + big job now, project now, is the translation of the FAQ, and the big + project will be the manual pages

+ + + + + FreeBSD GNOME Project + + + + + Joe + Marcus + + + marcus@FreeBSD.org + + + + Maxim + Sobolev + + + sobomax@FreeBSD.org + + + + Adam + Weinberger + + + adamw@FreeBSD.org + + + + + + FreeBSD GNOME Project + Homepage. + + + +

Since the ports tree has been frozen for most of this reporting period, + there have not been too many GNOME updates going into the official CVS + tree. However, development has not stopped. GNOME 2.2 is nearing + completion, and quite a few FreeBSD users have stepped up to test the + GNOME 2.1 port sources from the + MarcusCom + CVS repository. If anyone else is interested, follow the + instructions on the aforementioned cvsweb URL, and checkout the "ports" + module.

+ +

The upcoming FreeBSD 5.0-RELEASE will be the first release to have the + GNOME 2.0 desktop as the default GNOME desktop choice. During the + previously mentioned ports freeze, all the GNOME 2 ports were fixed up + so that they build and package on both i386 and Alpha platforms. Alas, + the one port that will not make the cut for Alpha is Mozilla. There are + still problems with the xpcom code, but work is ongoing to get a working + Alpha port.

+ +

Finally, the FreeBSD Mono (an OpenSource C# runtime) port has also + received some new life. Mono has been updated to 0.17 (the latest + released version), and Juli Mallett has ported gtk-sharp (GTK+ bindings + for C#).

+ + + + + FreeBSD/ia64 Status + + + + + Peter + Wemm + + + peter@FreeBSD.org + + + + Marcel + Moolenaar + + + marcel@FreeBSD.org + + + + + + + + + +

The ia64 port is up and running on the new Itanium2 based hp + machines thanks to a lot of hard work by Marcel Moolenaar. So + far we are running on the hp rx2600 as these were the machines + graciously donated by Hewlett-Packard and Intel. We had a + prototype Intel Tiger4 system for a while, but we had to return + the machine and we do not know if it currently runs. Most of + the changes necessary to run these are sitting in the perforce + tree and are not in the -current or RELENG_5 cvs tree. As a + result, the cvs derived builds (-current and the 5.0-RC series + and presumably 5.0-RELEASE) are only useable on obsolete Itanium1 + systems.

+ +

Lots of other stability and functionality fixes have been made + over the last few months, including initial libc_r support. The + OS appears to be stable enough for sustained workloads - it is + building packages now, for example. We still do not have gdb + support, even for reading core files.

+ + + + + jpman project + + + + + Kazuo + Horikawa + + + horikawa@FreeBSD.org + + + + + jpman project + + + +

We have been updating our Japanese translated manual pages to + RELENG_5 based. All existing entries have been updated, but 15 + exceptions are not, most of which require massive update. We + will also need to add translations which did not exist on RELENG_4.

+ + + + + KGI/FreeBSD Status Report + + + + + Nicholas + Souchu + + + nsouch@FreeBSD.org + + + + + + + + + +

KGI (Kernel Graphic Interface) is a kernel infrastructure providing user + applications with means to access hardware graphic resources (dma, + irqs, mmio). KGI is already available under Linux as a seperate + standalone project. The KGI/FreeBSD project aims at integrating KGI + in the FreeBSD kernel.

+ +

KGI/FreeBSD has been recently donated 2 PCI graphic cards (Matrox + Millenium II and a coming Mach64) and other have been proposed. + Please see the FreeBSD web pages for details. Thanks to donation@ for + organizing and promoting donations. Thanks to the donators for their + contribution to KGI/FreeBSD.

+ +

KGI/FreeBSD progressed fine the last months. Most of the VM issues for + mapping HW resources in user space have been addressed and a first + attempt of coding was made. This prototyping raised some API + compatibility problems with the current Linux implementation and was + discussed heavily on the kgi devel lists. Ask if you're + interested in such issues, I'll be pleased to share them.

+ +

Most of coding is now done. Let's start debugging!

+ + + + + SMP locking for network stack + + + + + Jeffrey + Hsu + + + hsu@FreeBSD.org + + + + +

Work is ongoing to continue to lock up the network stack. + Recently, the focus has been on the IP stack. The plan there + involves a series of inter-related pieces to lock up the + ifaddr ref count, the inet list, the ifaddr uses, the ARP code, + the routing tree, and the routing entries. We are over 3/5 of + the way done down this path.

+ +

In addition to TCP and UDP, the other networking protocols + such as raw IP, IPv6, AppleTalk, and XNS need to be locked up. + Around 1/4 these remaining protocols have been locked and + will be commited after the IP stack is locked.

+ +

The protocol independent socket layer needs to be locked and + operating correctly with the protocol dependent locks. This + part is mostly done save for much needed testing and code cleanup.

+ +

Finally, a pass will be need to be made to lock up the devices drivers + and various statistics counters.

+ + + + + TCP congestion control + + + + + Jeffrey + Hsu + + + hsu@FreeBSD.org + + + + + + + +

This effort fixes some outstanding problems in our TCP + stack with regard to congestion control. The first + item is to fix our NewReno implementation. Following that, + the next urgent correction is to fix a problem involving window updates + and dupack counts. When that stabilizes, we will then change + the recovery code to make use of SACK information. + Eventually, this project will update the BSD stack to add Limited Transmit + and other new internet standards and standards-track improvements.

+ + + + + FreeBSD Package Cluster work + + + + + Kris + Kennaway + + + kris@FreeBSD.org + + + + + + + + +

The 3 FreeBSD package clusters (i386, alpha, sparc64) have been + unified to run from the same master machine, instead of using 3 + separate masters. This has freed up some machine resources to + use as additional client machine, as well as simplifying + administrative overheads. Build logs for all 3 architectures + can now be found on the http://bento.freebsd.org webpage. The + sparc64 package cluster now has 3 build machines (an u5 and two + u10s), and an ia64 cluster is about to be created.

+ +

Package builds now keep track of how many sequential times a + port has failed to build (html summaries are available on the + bento website). This allows tracking of ports which have + suddenly become broken (e.g. due to a bad upgrade, or due to + changes in the FreeBSD source tree), and in the future will be + used to send out notifications to port maintainers when their + port fails to build 5 times in a row. This feature is currently + experimental, and further code changes will be needed to + stabilize it.

+ + + + + Wireless Networking Status + + + + + Sam + Leffler + + + sam@FreeBSD.org + + + + +

The goal of this project is to improve the wireless networking support in + the system. By the time of this report the 802.11 link layer code should + be committed. A version of the wi driver that uses this code should be + committed shortly. Conversion of other drivers is planned as are drivers + for new devices.

+ +

Support for 802.1x/EAP is the next planned milestone (both as a + supplicant and authenticator).

+ + + + + FreeBSD Release Engineering + + + + + Scott + Long + + + re@FreeBSD.org + + + + + Release Enginerring + Homepage + + + +

November and December were especially busy for the release egineering + team. Scott Long joined the team to help with secretary and + communications tasks while Brian Somers bowed out to focus on other + projects.

+ +

FreeBSD 5.0-DP2 was released in November after much delay and + anticipation, and marked the final milestone needed for 5.0 to + become a reality. Shortly after that, we imposed a code freeze on + the HEAD branch of CVS and released 5.0-RC1. Creation of the + RELENG_5_0 branch came next, followed by the release of 5.0-RC2 from + this branch. At this point, enough critical problems still existed + that we scheduled an RC3 release for the new year, and pushed the + final 5.0-RELEASE date to mid-January. By the time this is published, + FreeBSD 5.0-RELEASE should be a reality.

+ +

For the time being, there will not be a RELENG_5 (aka 5-STABLE) + branch. FreeBSD 4.x releases will continue, with 4.8 being + scheduled for March 2003. Release in the 4.x series will be + lead by Murray Stokely, and releases in the 5.x series will be + lead by Scott Long. Once HEAD has reached acceptable performance + and stability goals, the RELENG_5 branch will be created and HEAD + will move towards 6.0 development. We hope to reach this with + the 5.1 release this spring.

+ + + + + SMP aware scheduler + + + + + Jeff + Roberson + + + jeff@FreeBSD.org + + + + +

A new scheduler will be available as an optional component along side + the current scheduler in the 5.1 release. It has been designed to + work well with KSE and SMP. Some ideas have been borrowed from solaris + and linux along with many novel approaches. It has O(1) performance + with regard to the number of processes in the system. It also has + cpu affinity which should provide a speed boost for many applications.

+ +

The scheduler has a few loose ends and lots of tuning before it is + production quality although it is quite stable. Please see the post + to arch and subsequent discussion for more details.

+ + + diff --git a/en/news/status/report-nov-2002-dec-2002.xml b/en/news/status/report-nov-2002-dec-2002.xml new file mode 100644 index 0000000000..43a9b5d27c --- /dev/null +++ b/en/news/status/report-nov-2002-dec-2002.xml @@ -0,0 +1,875 @@ + + + November-December + 2002 + + +
+ Introduction: + +

At long last, FreeBSD 5.0 is here. Along with putting the final + polish on the tree, FreeBSD developers somehow found the time to + work on other things too. IA64 took some major steps towards + working on the Itanium2 platform, an effort was started to + convert all drivers to use busdma and ban vtophys(), hardware + crypto support and DEVD hit the tree, NewReno was fixed and + effort began on locking down the network layer of the kernel. + Also high performance, modular scheduler started taking shape + and will be a welcome addition to the kernel soon.

+ +

Looking forward, the focus will be on stabilizing and + improving the performance of 5.0. The RELENG_5 (aka 5-STABLE) + branch will be created once we've reached our goals in this + area, so hopefully we will get there quickly. Meanwhile, + preparations for the next release from the 4.x series, 4.8, + will begin soon. Of course, the best way to get 5.x to + stabilize os to install and run it!

+ +

Thanks,

+ +

Scott Long, Robert Watson

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

I'm very pleased to announce that all kernel modules and few userland + tools made it to the FreeBSD source tree. Many thanks to Julian + Elischer.

+ +

Unfortunately no big changes since the last report. Some minor problems + have been discovered and patches are available on request. I will prepare + all the patches and submit them to Julian for review.

+ +

OBEX server and client (based on OpenOBEX library) is almost complete. + I'm currently doing interoperability testing. If anyone has hardware and + time please contact me. The HCI security daemon has been implemented and + tested with Sony Ericsson T68i cell phone and Windows stack. It is now + possible to setup secure Bluetooth connections.

+ +

A few people have complained about RFCOMM daemon. These individuals want + to use GPRS and Bluetooth enabled cell phone to access Internet. If you + have this problem please contact me for possible workaround. My next goal + is to get robust RFCOMM implementation to address all these issues.

+ + + + + TrustedBSD Project: Access Control Lists + + + + + Robert + + Watson + + + rwatson@FreeBSD.org + + + + TrustedBSD Discussion List + + + trustedbsd-discuss@TrustedBSD.org + + + + + TrustedBSD Project + + + +

Largely bug-fixing and userland application tweaks; new + interfaces were added to manipulate ACLs on extended attributes; + bugs were fixed in ls relating to ACL flagging. Patches to + teach cp, mv, gzip, bzip, and other apps about ACL preservation + are in testing and review. tunefs flags were added to ease + configuration of ACLs, especially on UFS2 file systems.

+

Possible changes to make use of Linux/Solaris umask semantics + are under consideration: right now we implement verbatim + POSIX.1e/IRIX merging of the umask, ACL mask, and requested + creation mode during file, device, fifo, and directory creation. + Solaris and the most recent Linux patches ignore the umask in + the context of a default ACL; this requires some rearrangement + of umask handling in our VFS, although the results would be + quite useful. We're exploring how to do this in a low impact + way.

+ + + + + TrustedBSD Project: MAC Framework + + + + + Robert + + Watson + + + rwatson@FreeBSD.org + + + + TrustedBSD Discussion List + + + trustedbsd-discuss@TrustedBSD.org + + + + + TrustedBSD Project + + + +

Framework changes:

+

Instrument KLD system calls (module and kld load, unload, stat) + Instrument NFSd system call. Instrument swapoff(2). + Instrument per-architecture privileged parts of sysarch(). + Make use of condition variables to allow callers to wait for the + framework to "unbusy" when loading/unloading policies, rather than + returning EBUSY. Store mount pointer in devfs_mount structure for + use by policies. Improve handling of labels in loopback interface + "re-align" packet copy case. Provide full paths on devfs object + creations to help policies label them properly (not merged). + Experimentation with moving MAC labels into m_tags (not merged). + NFS server now uses real ucreds, not hacked up ucreds, + meaning we can start laying the groundwork for enforcement on + NFS operations. (not merged)

+ +

Policy changes

+

LOMAC: mac_lomac replaces lomac (LOMAC now uses the MAC Framework), + SEBSD: Improved support for devfs labeling based on SELinux genfs. + Handling of hard link checks. Support export of process transition + information for login and others using sysctl. Login now prompts + for roles. Allow policy reload. TTY labeling. Locking adaptation + from Linux. Many, many policy adaptations and fixes. We can + now boot in enforcing mode! mac_bsdextended: fix a bug in which + VAPPEND wasn't mapped to VWRITE, so opens with the O_APPEND bug + failed improperly.

+ +

Userland changes

+

setfmac(8) now supports a setfsmac(8) execution mode, which accepts + initial labeling specification files. Supports an SELinux compatibility + mode so it can accept SELinux label specfiles using the SEBSD module. + sendmail(8) now sets user labels as part of the context switch for mail + delivery.

+ +

Documentation changes

+

Man page updates for MAC command line tools, modules, admin hints, etc. + Updates to the FreeBSD Developer's Handbook chapter on MAC policies + and entry points. MAC section in FreeBSD Handbook.

+ + + + + busdma driver conversion project + + + + + Maxime + + Henrion + + + mux@FreeBSD.org + + + + + + + + +

This project has been coming along pretty well. The amd(4) and + xl(4) drivers have now been converted to use the busdma API, + sparc64 got the bus_dmamap_load_mbuf() and bus_dmamap_load_uio() + functions, and the gem(4) and hme(4) drivers have been updated + to use bus_dmamap_load_mbuf() instead of bus_dmamap_load().

+ +

A lot more still needs to be done, as shown on the project's + page. A fair number of conversions are on their way though, + and we can expect a fair number of drivers to be converted + soon, thanks to all the developers who are working on this + project.

+ + + + + FreeBSD C99 & POSIX Conformance Project + + + + + Mike + Barcroft + + + mike@FreeBSD.org + + + + FreeBSD-Standards Mailing List + + + standards@FreeBSD.org + + + + + + + + + +

The POSIX Utility Conformance in FreeBSD list (link above) has + been updated to reflect current reality. Not much work remains + to complete base utility conformance.

+ +

On the API front, grantpt(), posix_openpt(), unlockpt(), + wordexp(), and wordfree() were implemented. The header + <wordexp.h> was added.

+ +

There are currently about 40 unassigned tasks on our project's + status board ranging from documentation, utilities, to kernel + hacking. We would encourage any developers looking for something + to work on to check out the status board and see if anything + interests them.

+ + + + + Hardware Crypto Support Status + + + + + Sam + Leffler + + + sam@FreeBSD.org + + + + +

The goal of this project is to import the OpenBSD kernel-level crypto + subsystem. This facility provides kernel- and user-level access to + hardware crypto devices for the calculation of cryptographic hashes, + ciphers, and public key operations. The main clients of this facility + are the kernel RNG (/dev/random), network protocols (e.g. IPsec), and + OpenSSL (through the /dev/crypto device).

+ +

This work will be part of the 5.0 release and has been committed to + the -stable source tree for inclusion in the 4.8 release.

+ +

Recent work has focused on improving performance. System statistics are + now maintained and an optional profiling facility was added for + analyzing performance. Using this facility the overhead for using the + crypto API has been significantly reduced.

+ +

The ubsec (Broadcom) driver was changed to significantly improve + performance under load. In addition several memory leaks were fixed in + the driver and the public key support was enabled for use.

+ +

Upcoming work will focus on load-balancing requests across multiple + crypto devices and integrating OpenSSL 0.9.7 which will automatically + enable application use of crypto hardware.

+ + + + + DEVD + + + + + Warner + Losh + + + imp@FreeBSD.org + + + + +

Devd has been integrated into FreeBSD 5.0-RELEASE. The + integrated code supports a range of configuration options. The + config files are fully parsed now and their actions are + performed.

+ +

Future work in this area are likely to be limited to imporving + the devctl interface. /dev/devctl likely will be a cloneable + device in future versions. Individual device control via devctl + is also planned.

+ + + + + Donations Team Status Report + + + + + Michael + Lucas + + + donations@FreeBSD.org + + + + + Donations main page + FreeBSD + developer wantlist + + completed donations + + + +

The Donations project expedited several dozen donations during + 2002, and was able to place most of what was offered. We still + are in dire need of SMP and Sparc systems. You can see + information on our needs and donations that have been handled by + the team on the donations web page.

+ +

We are relying increasingly upon the developer wantlist to + place items offered to the Project, and using the commit + statistics to help place items. As such, active committers who + ask for what they want beforehand have a decent chance of + getting it. Less active committers, and committers who do not + ask for what they want, will be lower in our priorities but will + not be excluded.

+ +

We are in the process of streamlining the tax deduction process + for donations, and hope to have news on that shortly. We are + also always working to accelerate and reduce our internal + processes, to get the most equipment in the hands of the most + people as quickly as possible.

+ +

I especially want to thank David O'Brien and Tom Rhodes for + stepping up and making the team far more successful. Also, the + FreeBSD Foundation has been quite helpful in handling + tax-deductible contributions.

+ + + + + + + Fast IPsec Status + + + + + Sam + Leffler + + + sam@FreeBSD.org + + + + +

The main goal of this project is to modify the IPsec protocols to use + the kernel-level crypto subsystem imported from OpenBSD (see elsewhere). + A secondary goal is to do general performance tuning of the IPsec + protocols.

+ +

This work will be part of the 5.0 release. Performance has been improved + due to work on the crypto subsystem.

+ + + + + FFS volume label support + + + + + Gordon + Tetlow + + + gordon@FreeBSD.org + + + + + Current patch set. + + + +

The goal of the project is to use a small amount of space in the FFS + superblock to store a volume label of the user's choice. A GEOM module + will then expose the volume labels into a namespace in devfs. The idea + is to make it easier to manage filesystems across disk swaps and + movement from system to system.

+ +

At this point, everything pretty much works. I've submitted parts of + the patch to respective subsystem maintainers for review. There are some + issues with namespace collision that I haven't addressed yet, but the + basic functionality is there

+ + + + + French FreeBSD Documentation Project + + + + Sebastien + Gioria + + + gioria@FreeBSD.org + + + + Marc + Fonvieille + + blackend@FreeBSD.org + + + + Stéphane + Legrand + + stephane@FreeBSD.ORG + + + + + The French FreeBSD Documentation Project. + The FreeBSD Web Server translated in French. + Translation of the hanbook. + French Daemon News like web site. + + + +

Most of the articles are translated too. Marc is still translating the + handbook, 60% is currently translated. Stéphane has began the + integration of our French localization web site in the US CVS Tree. + Sébastien is still maintaining the Release Notes.

+ +

We launched a new site, www.FreeBSD-fr.info, consisting in a French + Dameon News like site. Netasq have donated our new server; we will + install it in a new hosting provider in the few next weeks. One of the + big job now, project now, is the translation of the FAQ, and the big + project will be the manual pages

+ + + + + FreeBSD GNOME Project + + + + + Joe + Marcus + + + marcus@FreeBSD.org + + + + Maxim + Sobolev + + + sobomax@FreeBSD.org + + + + Adam + Weinberger + + + adamw@FreeBSD.org + + + + + + FreeBSD GNOME Project + Homepage. + + + +

Since the ports tree has been frozen for most of this reporting period, + there have not been too many GNOME updates going into the official CVS + tree. However, development has not stopped. GNOME 2.2 is nearing + completion, and quite a few FreeBSD users have stepped up to test the + GNOME 2.1 port sources from the + MarcusCom + CVS repository. If anyone else is interested, follow the + instructions on the aforementioned cvsweb URL, and checkout the "ports" + module.

+ +

The upcoming FreeBSD 5.0-RELEASE will be the first release to have the + GNOME 2.0 desktop as the default GNOME desktop choice. During the + previously mentioned ports freeze, all the GNOME 2 ports were fixed up + so that they build and package on both i386 and Alpha platforms. Alas, + the one port that will not make the cut for Alpha is Mozilla. There are + still problems with the xpcom code, but work is ongoing to get a working + Alpha port.

+ +

Finally, the FreeBSD Mono (an OpenSource C# runtime) port has also + received some new life. Mono has been updated to 0.17 (the latest + released version), and Juli Mallett has ported gtk-sharp (GTK+ bindings + for C#).

+ + + + + FreeBSD/ia64 Status + + + + + Peter + Wemm + + + peter@FreeBSD.org + + + + Marcel + Moolenaar + + + marcel@FreeBSD.org + + + + + + + + + +

The ia64 port is up and running on the new Itanium2 based hp + machines thanks to a lot of hard work by Marcel Moolenaar. So + far we are running on the hp rx2600 as these were the machines + graciously donated by Hewlett-Packard and Intel. We had a + prototype Intel Tiger4 system for a while, but we had to return + the machine and we do not know if it currently runs. Most of + the changes necessary to run these are sitting in the perforce + tree and are not in the -current or RELENG_5 cvs tree. As a + result, the cvs derived builds (-current and the 5.0-RC series + and presumably 5.0-RELEASE) are only useable on obsolete Itanium1 + systems.

+ +

Lots of other stability and functionality fixes have been made + over the last few months, including initial libc_r support. The + OS appears to be stable enough for sustained workloads - it is + building packages now, for example. We still do not have gdb + support, even for reading core files.

+ + + + + jpman project + + + + + Kazuo + Horikawa + + + horikawa@FreeBSD.org + + + + + jpman project + + + +

We have been updating our Japanese translated manual pages to + RELENG_5 based. All existing entries have been updated, but 15 + exceptions are not, most of which require massive update. We + will also need to add translations which did not exist on RELENG_4.

+ + + + + KGI/FreeBSD Status Report + + + + + Nicholas + Souchu + + + nsouch@FreeBSD.org + + + + + + + + + +

KGI (Kernel Graphic Interface) is a kernel infrastructure providing user + applications with means to access hardware graphic resources (dma, + irqs, mmio). KGI is already available under Linux as a seperate + standalone project. The KGI/FreeBSD project aims at integrating KGI + in the FreeBSD kernel.

+ +

KGI/FreeBSD has been recently donated 2 PCI graphic cards (Matrox + Millenium II and a coming Mach64) and other have been proposed. + Please see the FreeBSD web pages for details. Thanks to donation@ for + organizing and promoting donations. Thanks to the donators for their + contribution to KGI/FreeBSD.

+ +

KGI/FreeBSD progressed fine the last months. Most of the VM issues for + mapping HW resources in user space have been addressed and a first + attempt of coding was made. This prototyping raised some API + compatibility problems with the current Linux implementation and was + discussed heavily on the kgi devel lists. Ask if you're + interested in such issues, I'll be pleased to share them.

+ +

Most of coding is now done. Let's start debugging!

+ + + + + SMP locking for network stack + + + + + Jeffrey + Hsu + + + hsu@FreeBSD.org + + + + +

Work is ongoing to continue to lock up the network stack. + Recently, the focus has been on the IP stack. The plan there + involves a series of inter-related pieces to lock up the + ifaddr ref count, the inet list, the ifaddr uses, the ARP code, + the routing tree, and the routing entries. We are over 3/5 of + the way done down this path.

+ +

In addition to TCP and UDP, the other networking protocols + such as raw IP, IPv6, AppleTalk, and XNS need to be locked up. + Around 1/4 these remaining protocols have been locked and + will be commited after the IP stack is locked.

+ +

The protocol independent socket layer needs to be locked and + operating correctly with the protocol dependent locks. This + part is mostly done save for much needed testing and code cleanup.

+ +

Finally, a pass will be need to be made to lock up the devices drivers + and various statistics counters.

+ + + + + TCP congestion control + + + + + Jeffrey + Hsu + + + hsu@FreeBSD.org + + + + + + + +

This effort fixes some outstanding problems in our TCP + stack with regard to congestion control. The first + item is to fix our NewReno implementation. Following that, + the next urgent correction is to fix a problem involving window updates + and dupack counts. When that stabilizes, we will then change + the recovery code to make use of SACK information. + Eventually, this project will update the BSD stack to add Limited Transmit + and other new internet standards and standards-track improvements.

+ + + + + FreeBSD Package Cluster work + + + + + Kris + Kennaway + + + kris@FreeBSD.org + + + + + + + + +

The 3 FreeBSD package clusters (i386, alpha, sparc64) have been + unified to run from the same master machine, instead of using 3 + separate masters. This has freed up some machine resources to + use as additional client machine, as well as simplifying + administrative overheads. Build logs for all 3 architectures + can now be found on the http://bento.freebsd.org webpage. The + sparc64 package cluster now has 3 build machines (an u5 and two + u10s), and an ia64 cluster is about to be created.

+ +

Package builds now keep track of how many sequential times a + port has failed to build (html summaries are available on the + bento website). This allows tracking of ports which have + suddenly become broken (e.g. due to a bad upgrade, or due to + changes in the FreeBSD source tree), and in the future will be + used to send out notifications to port maintainers when their + port fails to build 5 times in a row. This feature is currently + experimental, and further code changes will be needed to + stabilize it.

+ + + + + Wireless Networking Status + + + + + Sam + Leffler + + + sam@FreeBSD.org + + + + +

The goal of this project is to improve the wireless networking support in + the system. By the time of this report the 802.11 link layer code should + be committed. A version of the wi driver that uses this code should be + committed shortly. Conversion of other drivers is planned as are drivers + for new devices.

+ +

Support for 802.1x/EAP is the next planned milestone (both as a + supplicant and authenticator).

+ + + + + FreeBSD Release Engineering + + + + + Scott + Long + + + re@FreeBSD.org + + + + + Release Enginerring + Homepage + + + +

November and December were especially busy for the release egineering + team. Scott Long joined the team to help with secretary and + communications tasks while Brian Somers bowed out to focus on other + projects.

+ +

FreeBSD 5.0-DP2 was released in November after much delay and + anticipation, and marked the final milestone needed for 5.0 to + become a reality. Shortly after that, we imposed a code freeze on + the HEAD branch of CVS and released 5.0-RC1. Creation of the + RELENG_5_0 branch came next, followed by the release of 5.0-RC2 from + this branch. At this point, enough critical problems still existed + that we scheduled an RC3 release for the new year, and pushed the + final 5.0-RELEASE date to mid-January. By the time this is published, + FreeBSD 5.0-RELEASE should be a reality.

+ +

For the time being, there will not be a RELENG_5 (aka 5-STABLE) + branch. FreeBSD 4.x releases will continue, with 4.8 being + scheduled for March 2003. Release in the 4.x series will be + lead by Murray Stokely, and releases in the 5.x series will be + lead by Scott Long. Once HEAD has reached acceptable performance + and stability goals, the RELENG_5 branch will be created and HEAD + will move towards 6.0 development. We hope to reach this with + the 5.1 release this spring.

+ + + + + SMP aware scheduler + + + + + Jeff + Roberson + + + jeff@FreeBSD.org + + + + +

A new scheduler will be available as an optional component along side + the current scheduler in the 5.1 release. It has been designed to + work well with KSE and SMP. Some ideas have been borrowed from solaris + and linux along with many novel approaches. It has O(1) performance + with regard to the number of processes in the system. It also has + cpu affinity which should provide a speed boost for many applications.

+ +

The scheduler has a few loose ends and lots of tuning before it is + production quality although it is quite stable. Please see the post + to arch and subsequent discussion for more details.

+ + + diff --git a/en/news/status/status.sgml b/en/news/status/status.sgml index 3797e095e6..1eaa68ba6e 100644 --- a/en/news/status/status.sgml +++ b/en/news/status/status.sgml @@ -1,60 +1,62 @@ - + %includes; ]> &header;

One of the benefits of the FreeBSD development model is a focus on centralized design and implementation, in which the operating system is maintained in a central repository, and discussed on centrally maintained lists. This allows for a high level of coordination between authors of various components of the system, and allows policies to be enforced over the entire system, covering issues ranging from architecture to style. However, as the FreeBSD developer community has grown, and the rate of both mailing list traffic and tree modifications has increased, making it difficult even for the most dedicated developer to remain on top of all the work going on in the tree.

The FreeBSD Bi-Monthly Development Status Report attempts to address this problem by providing a vehicle that allows developers to make the broader community aware of their on-going work on FreeBSD, both in and out of the central source repository. For each project and sub-project, a one paragraph summary is included, indicating progress since the last summary. If it is a new project, or if a project has not submitted any prior status reports, a short description may precede the status information.

These status reports may be reproduced in whole or in part, as long as the source is clearly identified and appropriate credit given.

2002

2001

&footer;