aboutsummaryrefslogtreecommitdiff
path: root/en/news/status/report-2001-06.xml
diff options
context:
space:
mode:
Diffstat (limited to 'en/news/status/report-2001-06.xml')
-rw-r--r--en/news/status/report-2001-06.xml826
1 files changed, 0 insertions, 826 deletions
diff --git a/en/news/status/report-2001-06.xml b/en/news/status/report-2001-06.xml
deleted file mode 100644
index 4904ce5fa2..0000000000
--- a/en/news/status/report-2001-06.xml
+++ /dev/null
@@ -1,826 +0,0 @@
-<!-- $FreeBSD: www/en/news/status/report-june-2001.xml,v 1.6 2003/04/13 16:31:52 hrs 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.6 2003/04/13 16:31:52 hrs 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 &lt;
- <a href="mailto:rwatson@FreeBSD.org">rwatson@FreeBSD.org</a>
-
- &gt;</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
- &lt;johnp@knight-trosoft.com&gt;, 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/&lt;pid&gt;/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/&lt;pid&gt;/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 &amp; 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>