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 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. This is the first issue, and as such is an + experiment. For each project and sub-project, a one paragraph summary is + included, indicating progress since the last summary (in this case, simply + recent progress, as there have been no prior summaries).
+ +This status report may be reproduced in whole or in part, as long as the + source is clearly identified and appropriate credit given.
+ +Assuming there is some positive feedback on this idea, and that future + submissions get made such that there is content for future issues, the + goal is to release a development status report once a month. As such, the + next deadline will be July 31, 2001, with a scheduled publication date in + the first week of August. This will put the status report on a schedule + in line with the calendar, as well as providing a little over a month + until the next deadline, which will include a number of pertinent events, + including the Annual USENIX Technical Conference in Boston, MA. + Submissions should be e-mailed to:
+ ++ robert+freebsd.monthly@cyrus.watson.org+ +
Many submitters will want to wait until the last week of July so as to + provide the most up-to-date status report; however, submissions will be + accepted at any time prior to that date.
+ +-- Robert Watson <rwatson@FreeBSD.org>
+ +The following projects submitted summaries for the June 2001 report:
+ +Contacts: Eric Melville <eric@FreeBSD.org>, Murray Stokely <murray@FreeBSD.org>
+URL: http://people.freebsd.org/~murray/updater.html
+ +The FreeBSD Binary Updater Project aims to provide a secure mechanism + for the distribution of binary updates for FreeBSD. This project is + complementary to the Open Packages and libh efforts and there should + be very little overlap with those projects. The system uses a client + / server mechanism that allows clients to install any known "profile" + or release of FreeBSD over the network. Where a specific profile + might contain a specific set of FreeBSD software to install, + additional packages, and configuration actions that make it more + ideal for a specific environment (ie FreeBSD 4.3 Secure Web Server + Profile)
+ +The system can currently be used to install a FreeBSD system or + perform the most simple of upgrades but many features are absent. In + particular, the client is in its infancy and much work remains to be + done. We need additional developers so please get in touch with us + at updater@osd.bsdi.com + if you are interested in spending some cycles + on this.
+ +Contact: Poul-Henning Kamp <phk@FreeBSD.org>
+URL: http://phk.freebsd.dk/Gnats/
+ +Poul-Henning Kamp kicked off a drive to get our GNATS PR database + cleaned up so the wheat can be sorted from the chaff. Progress is + good, but there is still a lot of work to do. Give a hand if you + can. Remember: every unhandled PR is a pissed off contributor or + user.
+ +Contact: Josef Karthauser <joe@FreeBSD.org>
+ +I'm in the process of rewriting the CVSROOT/scripts to make them more + clean and configurable. A lot of other projects also use these and + so it makes sense to make them as easy to use in other environments as + possible.
+ +Status: work in progress. There is now a configuration file, but not + all the scripts use it yet.
+ +Contact: Poul-Henning Kamp <phk@FreeBSD.org>
+ +Work is progressing on implementing true cloning devices in DEVFS. + Brian Somers and Poul-Henning Kamp are working to make if_tun the + first truly cloning driver in the system. Next will be the pty + driver and the bpf driver.
+ +From July 1st DEVFS will be standard in -current.
+ +Contact: Brian Somers <brian@FreeBSD.org>
+ +Added the digi driver. Initial work was done by John Prince + <johnp@knight-trosoft.com>, but all the modular stuff was done by me + and initial work on supporting Xe and Xi cards (ala dgb) was done by + me. I'm now awaiting an Xe card being sent from joerg@ (almost a + donation) so that I can get that side of things working properly.
+ +Contact: Poul-Henning Kamp <phk@FreeBSD.org>
+URL: http://phantom.cris.net/freebsd/projects/viewproj.php?p_id=15
+ +Ben Smithurst has written a "diskcheckd" daemon which will read all + sectors on the disks over a configured period. With recent increases + in disksizes it is by no means a given that disk read errors will be + discovered before they are fatal. This daemon will hopefully result + in the drive firmware being able to relocate bad sectors before they + become unreadable. This code is now committed to 5.0-CURRENT.
+ +Contact: Jonathan Lemon <jlemon@FreeBSD.org>
+ +In the last month (May-June), the new fxp driver was brought + into -stable. This new driver uses the common MII code, so + support for new PHYs is easy to add. Support for the new Intel + 82562 chips was added. The driver was updated to add VLAN + support and a workaround for a bug affecting Intel 815-based boards.
+ +Contact: Greg Lewis <glewis@eyesbeyond.com>
+ +The FreeBSD Java Project has continued its "behind the scenes" work + over the last month. Progress was made both technically, with the + help of Bill Huey (of Wind River), on a port of JDK 1.3.1 and + legally, with Nate Williams continuing negotiations with Sun on a + mutually acceptable license to release a binary Java 2 SDK under. + The JDK 1.2.2 port has also seen some development, with a new + patchset likely to be released soon which includes JPDA and NetBSD + support (the latter courtesy of Scott Bartram).
+ +Contact: Nicolas Souchu <nsouch@fr.alcove.com>
+URL: http://kgi.sourceforge.net/
+ +The Kernel Graphics Interface project has worked for several years to + provide a framework for graphic drivers under Linux receiving input + from other groups like the UDI project. Currently the KGI core + implementation is quite settled, as is the driver coding model as a + whole. Work is being done to newbussify KGI and produce a kld, as + part of a future redesign of the graphics subsystem in FreeBSD. KGI + will be an alternative for graphic card producers that don't accept + the XFree86 model of userland graphic adapters and will also provide + accelerated support for any other graphic alternative.
+ +Contacts: Alexander Langer <alex@FreeBSD.org>, Nathan Ahlstrom <nra@FreeBSD.org>
+URL: http://people.freebsd.org/~alex/libh/
+ +The libh project is a next generation sysinstall. It is written + in C++ using QT for its graphical frontend and tvision for its console + support. The menus are scriptable via an embedded tcl interpreter. + It has been growing functionality quite a bit lately, including a new + disklabel editor. Current work is on installation scripts for CDROM, + FTP, ... installs as well as a fully functional standalone + disk-partition and label editor. The GUI API was extended a little + and many bugs were fixed. There seems to be some interest in i18n + work.
+ +Contact: Poul-Henning Kamp <phk@FreeBSD.org>
+ +Maxime Henrion is working on implementing a new and more extensible + mount(2) systemcall, mainly to overcome the 32 bits for mountoptions + limit, secondary goal to make it possible to mount filesystems from + inside the kernel.
+ +Contact: Warner Losh <imp@FreeBSD.org>
+ +In the last two months, the OLDCARD pccard implemenation was + rototilled to within an inch of its life. Many new pci cardbus + bridges were added. Power handling was improved. PCI Card cardbus + bridges are nearly supported and should be committed in early June to + the tree. This will likely be the last major work done on OLDCARD. + After pci cards are supported, work will shift to improving NEWCARD.
+ +Contact: Benno Rice <benno@FreeBSD.org>
+ +The PowerPC port is proceeding well. All seems to be working in + pmap.c after a number of problems encountered where FreeBSD passes a + vm_page_t to a NetBSD-derived function that expects a vm_offset_t. + Then after debugging the atomic operations code, I'm now at the point + where VM appears to be initialised and it's now hanging while in + sys/kern/kern_malloc.c:kmeminit(). Progress continues. =)
+ +Contact: Brian Somers <brian@FreeBSD.org>
+ +Developing full MPPE support for Andre Opperman @ Monzoon in + Switzerland. Work is now complete and will eventually be brought + into -current, but no dates are yet known.
+ +Contact: Dag-Erling Smorgrav <des@FreeBSD.org>
+ +Pseudofs is a framework for pseudo-filesystems, like procfs and + linprocfs. The goal of pseudofs is twofold:
+ +Pseudofs has reached the point where it is sufficiently + functional and stable that linprocfs has been almost fully + reimplemented on top of it; the only bit that's missing is the + proc/<pid>/mem file.
+ +The primary to-do item for pseudofs right now is to add support + for writeable files (which are required for procfs, and are quite + a bit less trivial to handle than read-only files). In addition, + pseudofs needs either generic support for raw (non-sbuf'ed, + possibly mmap'able) files, or failing that, special-case code to + handle proc/<pid>/mem.
+ +Contact: Bruce A. May <bmah@FreeBSD.org>
+URL: http://people.freebsd.org/~bmah/relnotes/
+ +RELNOTESng is the name I've given to the rewrite of the *.TXT files + that typically accompany a FreeBSD release. The information from + these files (which include, among other things, the release notes and + the supported hardware list) have been reorganized and converted to + SGML. This helps us produce the documentation in various formats, as + well as facilitating the maintainence of documentation for multiple + architectures. This work was recently committed to -CURRENT, and I + intend to MFC it to 4-STABLE before 4.4-RELEASE.
+ +Contacts: John Baldwin <jhb@FreeBSD.org>, Jake Burkholder <jake@FreeBSD.org>, SMP Mailing list <smp@FreeBSD.org>
+URL: http://www.freebsd.org/~jasone/smp/
+ +The SMPng project aims to provide multithreaded support for the + FreeBSD kernel. Currently the kernel still runs almost exclusively + under the Giant kernel lock. Recently, progress has been made in + locking the process group and session structures as well as file + descriptors by Seigo Tanimura-san. Alfred Perlstein has also added + in a giant lock around the entire virtual memory (VM) subsystem which + will eventually be split up into several smaller locks. The locking + of the VM subsystem has proved tricky, and some of the current effort + is focused on finding and fixing a few remaining bugs in on the alpha + architecture.
+ +Contact: Bosko Milekic <bmilekic@FreeBSD.org>
+URL: http://people.freebsd.org/~bmilekic/code/mb_slab/
+ +mb_alloc is a new specialized allocator for mbufs and mbuf clusters. + Presently, it offers various important advantages over the old + (status quo) mbuf allocator, particularily for MP machines. + Additionally, it is designed with the possibility of future + enchancements in mind.
+ +Presently in initial review & testing stages, most of the code is + already written.
+ +Contact: Jake Burkholder <jake@FreeBSD.org>
+ +Work has (re)started on a port of FreeBSD to the UltraSPARC + architecture, specifically targeting PCI based workstations. Jake + Burkholder will be porting the kernel, and Ade Lovett has expressed + an interest in working on userland. Recent work on the project + includes:
+ +At this point the kernel can be net-booted and prints the FreeBSD + copyright before calling code that is not yet implemented. I am + currently working on a design for the pmap module and plan to begin + implementation in the next few days.
+ +Contact: Robert Watson <rwatson@FreeBSD.org>
+URL: http://www.TrustedBSD.org/
+ +The TrustedBSD Project seeks to improve the security of the FreeBSD + operating system by adding new security features, many derived from + common trusted operating system requirements. This includes Access + Control Lists (ACLs), Fine-grained Event Logging (Audit), Fine-grained + Privileges (Capabilities), Mandatory Access Control (MAC), and other + architecture features, including file system extended attributes, + and improved object labeling.
+ +Individual feature status reports are documented seperately below; + in general, basic features (such as EAs, ACLs, and kernel support + for Capabilities) will be initially available in 5.0-RELEASE, + conditional on specific kernel options. A performance-enhanced + version of EAs is currently being targetted at 6.0-RELEASE, along + with an integrated capability-aware userland, and MAC support.
+ +Contact: Chris D. Faulhaber <jedgar@FreeBSD.org>
+ +Patches are now available to add ACL support to cp(1) and mv(1) along + with preliminary support for install(1). Ilmar's i18n patches for + getfacl(1) and setfacl(1) need to be updated for the last set of + changes and committed. Some other functional improvements are also + in the pipeline.
+ +Contact: Thomas Moestl <tmm@FreeBSD.org>
+ +The kernel part of the capability implementation is mostly finished; + all uses of suser() and suser_xxx() and nearly all comparisons of + uid's with 0 have been converted to use the newly introduced + cap_check() call. Some details still need clarification. More + documentation for this needs to be done.
+ +POSIX.2c-compatible getfcap and setfcap programs have been written. + Experimental capability support in su(1), login(1), install(1) and + bsd.prog.mk is being tested.
+ +Support for capabilities, ACL's, capabilities and MAC labels in + tar(1) is being developed; only the capability part is tested right + now. Generic support for extended attributes is planned, this will + require extensions to the current EA interface, which are written and + will probably be committed to -CURRENT in a few weeks. A port of + these features to pax(1) is planned.
+ +Contact: Robert Watson <rwatson@FreeBSD.org>
+URL: http://www.TrustedBSD.org/
+ +An initial prototype of a Mandatory Access Control implementation + was completed earlier this year, supporting Multi-Level Security, + Biba Integrity protection, and a more general jail-based access + control model. Based on that implementation, I'm now in the process + of improving the FreeBSD security abstractions to simplify both the + implementation and integration of MAC support, as well as increase the + number of kernel objects protected by both discretionary and mandatory + protection schemes. Generic object labeling introduces a structure + not dissimilar in properties to the kernel ucred structure, only it is + intended to be associated with kernel objects, rather than kernel + subjects, permitting the creation of generic security protection + routines for objects. This would allow the easy extension of procfs + and devfs to support ACLs and MAC, for example. A prototype is + underway, with compiling and running code and simple protections + now associated with sysctl's.
+ + &footer; + +