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,4 +1,4 @@ -# $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" @@ -21,6 +21,7 @@ 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 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,6 +1,6 @@ - + %includes; ]> @@ -33,6 +33,8 @@

2002