diff options
Diffstat (limited to 'en/news/status/report-2001-06.xml')
| -rw-r--r-- | en/news/status/report-2001-06.xml | 830 |
1 files changed, 0 insertions, 830 deletions
diff --git a/en/news/status/report-2001-06.xml b/en/news/status/report-2001-06.xml deleted file mode 100644 index 1dc4b81a35..0000000000 --- a/en/news/status/report-2001-06.xml +++ /dev/null @@ -1,830 +0,0 @@ -<?xml version="1.0" encoding="ISO-8859-1" ?> -<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status Report//EN" - "http://www.FreeBSD.org/XML/www/share/sgml/statusreport.dtd"> - -<!-- $FreeBSD: www/en/news/status/report-june-2001.xml,v 1.7 2004/04/04 21:46:14 phantom Exp $ --> - -<report> - <date> - <month>June</month> - - <year>2001</year> - </date> - - <cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0"> - <cvs:keyword name="freebsd"> - $FreeBSD: www/en/news/status/report-june-2001.xml,v 1.7 2004/04/04 21:46:14 phantom Exp $ - </cvs:keyword> - </cvs:keywords> - - <section> - <title>Introduction</title> - - <p>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.</p> - - <p>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).</p> - - <p>This status report may be reproduced in whole or in part, as - long as the source is clearly identified and appropriate credit - given.</p> - </section> - - <section> - <title>Future Editions</title> - - <p>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:</p> - - <blockquote> - <a href="mailto:robert+freebsd.monthly@cyrus.watson.org"> - robert+freebsd.monthly@cyrus.watson.org</a> - </blockquote> - - <p>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.</p> - - <p> - <i>-- Robert Watson < - <a href="mailto:rwatson@FreeBSD.org">rwatson@FreeBSD.org</a> - - ></i> - </p> - </section> - - <project> - <title>Binary Updater Project</title> - - <contact> - <person> - <name> - <given>Eric</given> - - <common>Melville</common> - </name> - - <email>eric@FreeBSD.org</email> - </person> - - <person> - <name> - <given>Murray</given> - - <common>Stokely</common> - </name> - - <email>murray@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://people.FreeBSD.org/~murray/updater.html" /> - </links> - - <body> - <p>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)</p> - - <p>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 - <a href="mailto:updater@osd.bsdi.com">updater@osd.bsdi.com</a> - - if you are interested in spending some cycles on this.</p> - </body> - </project> - - <project> - <title>Problem Reports</title> - - <contact> - <person> - <name> - <given>Poul-Henning</given> - - <common>Kamp</common> - </name> - - <email>phk@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://phk.freebsd.dk/Gnats/" /> - </links> - - <body> - <p>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.</p> - </body> - </project> - - <project> - <title>CVSROOT script rewrite/tidy</title> - - <contact> - <person> - <name> - <given>Josef</given> - - <common>Karthauser</common> - </name> - - <email>joe@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>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.</p> - - <p>Status: work in progress. There is now a configuration file, - but not all the scripts use it yet.</p> - </body> - </project> - - <project> - <title>DEVFS</title> - - <contact> - <person> - <name> - <given>Poul-Henning</given> - - <common>Kamp</common> - </name> - - <email>phk@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>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.</p> - - <p>From July 1st DEVFS will be standard in -current.</p> - </body> - </project> - - <project> - <title>digi driver</title> - - <contact> - <person> - <name> - <given>Brian</given> - - <common>Somers</common> - </name> - - <email>brian@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>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.</p> - </body> - </project> - - <project> - <title>Diskcheckd</title> - - <contact> - <person> - <name> - <given>Poul-Henning</given> - - <common>Kamp</common> - </name> - - <email>phk@FreeBSD.org</email> - </person> - </contact> - - <links> - <url - href="http://phantom.cris.net/freebsd/projects/viewproj.php?p_id=15" /> - </links> - - <body> - <p>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.</p> - </body> - </project> - - <project> - <title>if_fxp driver</title> - - <contact> - <person> - <name> - <given>Jonathan</given> - - <common>Lemon</common> - </name> - - <email>jlemon@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>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.</p> - </body> - </project> - - <project> - <title>Java Project</title> - - <contact> - <person> - <name> - <given>Greg</given> - - <common>Lewis</common> - </name> - - <email>glewis@eyesbeyond.com</email> - </person> - </contact> - - <body> - <p>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).</p> - </body> - </project> - - <project> - <title>Kernel Graphics Interface port</title> - - <contact> - <person> - <name> - <given>Nicolas</given> - - <common>Souchu</common> - </name> - - <email>nsouch@fr.alcove.com</email> - </person> - </contact> - - <links> - <url href="http://kgi.sourceforge.net/" /> - </links> - - <body> - <p>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.</p> - </body> - </project> - - <project> - <title>libh Project</title> - - <contact> - <person> - <name> - <given>Alexander</given> - - <common>Langer</common> - </name> - - <email>alex@FreeBSD.org</email> - </person> - - <person> - <name> - <given>Nathan</given> - - <common>Ahlstrom</common> - </name> - - <email>nra@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://people.FreeBSD.org/~alex/libh/" /> - </links> - - <body> - <p>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.</p> - </body> - </project> - - <project> - <title>Mount(2) API</title> - - <contact> - <person> - <name> - <given>Poul-Henning</given> - - <common>Kamp</common> - </name> - - <email>phk@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>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.</p> - </body> - </project> - - <project> - <title>OLDCARD pccard implementation</title> - - <contact> - <person> - <name> - <given>Warner</given> - - <common>Losh</common> - </name> - - <email>imp@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>In the last two months, the OLDCARD pccard implementation 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.</p> - </body> - </project> - - <project> - <title>PowerPC Port</title> - - <contact> - <person> - <name> - <given>Benno</given> - - <common>Rice</common> - </name> - - <email>benno@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>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 initialized and it's now - hanging while in sys/kern/kern_malloc.c:kmeminit(). Progress - continues. =)</p> - </body> - </project> - - <project> - <title>PPP</title> - - <contact> - <person> - <name> - <given>Brian</given> - - <common>Somers</common> - </name> - - <email>brian@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>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.</p> - </body> - </project> - - <project> - <title>pseudofs</title> - - <contact> - <person> - <name> - <given>Dag-Erling</given> - - <common>Smorgrav</common> - </name> - - <email>des@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>Pseudofs is a framework for pseudo-filesystems, like procfs - and linprocfs. The goal of pseudofs is twofold:</p> - - <ul> - <li>eliminate code duplication between (and within) procfs and - linprocfs</li> - - <li>isolate procfs and linprocfs from the complexities of the - vfs system to simplify maintenance and further - development.</li> - </ul> - - <p>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.</p> - - <p>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.</p> - </body> - </project> - - <project> - <title>RELNOTESng</title> - - <contact> - <person> - <name> - <given>Bruce</given> - - <common>A. Mah</common> - </name> - - <email>bmah@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://people.FreeBSD.org/~bmah/relnotes/" /> - </links> - - <body> - <p>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 maintenance 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.</p> - </body> - </project> - - <project> - <title>SMPng Project</title> - - <contact> - <person> - <name> - <given>John</given> - - <common>Baldwin</common> - </name> - - <email>jhb@FreeBSD.org</email> - </person> - - <person> - <name> - <given>Jake</given> - - <common>Burkholder</common> - </name> - - <email>jake@FreeBSD.org</email> - </person> - - <person> - <name> - <given>SMP</given> - - <common>Mailing list</common> - </name> - - <email>smp@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://www.FreeBSD.org/~jasone/smp/" /> - </links> - - <body> - <p>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.</p> - </body> - </project> - - <project> - <title>SMPng mbuf allocator</title> - - <contact> - <person> - <name> - <given>Bosko</given> - - <common>Milekic</common> - </name> - - <email>bmilekic@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://people.FreeBSD.org/~bmilekic/code/mb_slab/" /> - </links> - - <body> - <p>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, particularly for MP - machines. Additionally, it is designed with the possibility of - future enhancements in mind.</p> - - <p>Presently in initial review & testing stages, most of the - code is already written.</p> - </body> - </project> - - <project> - <title>Sparc64 Port</title> - - <contact> - <person> - <name> - <given>Jake</given> - - <common>Burkholder</common> - </name> - - <email>jake@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>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:</p> - - <ul> - <li>built a gnu cross toolchain targeting sparc64</li> - - <li>obtained remote access to an ultra 5 development machine - (thanks to emmy)</li> - - <li>developed a minimal set of headers and source files to - allow the kernel to be compiled and linked</li> - - <li>implemented a mini-loader which relocates the kernel, maps - it into the tlbs and calls it</li> - - <li>nabbed Benno Rice's openfirmware console driver which - allows printf and panic to work</li> - </ul> - - <p>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.</p> - </body> - </project> - - <project> - <title>TrustedBSD</title> - - <contact> - <person> - <name> - <given>Robert</given> - - <common>Watson</common> - </name> - - <email>rwatson@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://www.TrustedBSD.org/" /> - </links> - - <body> - <p>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.</p> - - <p>Individual feature status reports are documented separately - 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 targeted - at 6.0-RELEASE, along with an integrated capability-aware - userland, and MAC support.</p> - </body> - </project> - - <project> - <title>TrustedBSD: ACLs</title> - - <contact> - <person> - <name> - <given>Chris</given> - - <common>D. Faulhaber</common> - </name> - - <email>jedgar@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>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.</p> - </body> - </project> - - <project> - <title>TrustedBSD Capabilities</title> - - <contact> - <person> - <name> - <given>Thomas</given> - - <common>Moestl</common> - </name> - - <email>tmm@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>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.</p> - - <p>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.</p> - - <p>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.</p> - </body> - </project> - - <project> - <title>TrustedBSD MAC and Object Labeling</title> - - <contact> - <person> - <name> - <given>Robert</given> - - <common>Watson</common> - </name> - - <email>rwatson@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://www.TrustedBSD.org/" /> - </links> - - <body> - <p>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.</p> - </body> - </project> -</report> |