diff options
Diffstat (limited to 'en_US.ISO8859-1/htdocs/news/status/report-2005-01-2005-03.xml')
| -rw-r--r-- | en_US.ISO8859-1/htdocs/news/status/report-2005-01-2005-03.xml | 2147 |
1 files changed, 2147 insertions, 0 deletions
diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2005-01-2005-03.xml b/en_US.ISO8859-1/htdocs/news/status/report-2005-01-2005-03.xml new file mode 100644 index 0000000000..86e3a63a41 --- /dev/null +++ b/en_US.ISO8859-1/htdocs/news/status/report-2005-01-2005-03.xml @@ -0,0 +1,2147 @@ +<?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"> + +<report> + <date> + <month>January-April</month> + + <year>2005</year> + </date> + + <section> + <title>Introduction</title> + + <p>The first quarter of 2005 has been extremely active in both + FreeBSD-CURRENT and -STABLE. With FreeBSD 5.4 in the final RC stage + and an anticipated branch of FreeBSD-6 this summer we have seen a lot + of performance improvements in 5 and a couple of exciting new + features in 6.</p> + + <p>The report turnout was extremely good and it seems that the + webform provided by Julian Elischer has made it more enjoyable to + write reports. Many thanks to Julian for providing this. We also + like to get your attention to the open tasks section provided in some + reports.</p> + + <p>On special note, please take a look at the report about the + upcoming BSDCan in Ottawa. There will be lots of interesting FreeBSD + related talks and activities. If you enjoy reading these reports, you + will love the conference. See you there!</p> + + <p>Thanks to all the reporters, we hope you enjoy reading.</p> + </section> + + <category> + <name>proj</name> + + <description>Projects</description> + </category> + + <category> + <name>doc</name> + + <description>Documentation</description> + </category> + + <category> + <name>kern</name> + + <description>Kernel</description> + </category> + + <category> + <name>net</name> + + <description>Network infrastructure</description> + </category> + + <category> + <name>bin</name> + + <description>Userland programs</description> + </category> + + <category> + <name>arch</name> + + <description>Architectures</description> + </category> + + <category> + <name>ports</name> + + <description>Ports</description> + </category> + + <category> + <name>vendor</name> + + <description>Vendor / 3rd Party Software</description> + </category> + + <category> + <name>misc</name> + + <description>Miscellaneous</description> + </category> + + <project cat='proj'> + <title>Secure Updating</title> + + <contact> + <person> + <name> + <given>Colin</given> + + <common>Percival</common> + </name> + + <email>cperciva@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.daemonology.net/portsnap/" /> + + <url href="http://www.daemonology.net/freebsd-update/" /> + </links> + + <body> + <p>Shortly before the ports freeze for FreeBSD 5.4, I released a + new version of Portsnap. In addition to being secure and more + efficient than CVSup, this latest version distributes INDEX, + INDEX-5, and INDEX-6 files, thereby eliminating the need to run + "make fetchindex" and ensuring that the ports INDEX will match the + existing ports tree. In addition, portsnap builds have now moved + onto hardware managed by the FreeBSD project, thereby sharply + increasing portsnap's chances of survival if I get hit by a + bus.</p> + + <p>In early February hardware problems caused both FreeBSD Update + and Portsnap to stop functioning for a few days, but those were + resolved thanks to a server donated by layeredtech.com.</p> + + <p>I intend bring Portsnap into the FreeBSD base system before the + end of the month, followed by FreeBSD Update a few months + later.</p> + </body> + </project> + + <project cat='project'> + <title>if_bridge from NetBSD</title> + + <contact> + <person> + <name> + <given>Andrew</given> + + <common>Thompson</common> + </name> + + <email>andy@fud.org.nz</email> + </person> + </contact> + + <links> + <url href="http://www.fud.org.nz/~andy/if_bridge.diff" /> + </links> + + <body> + <p>This project aims to import the bridging code and interface from + NetBSD and OpenBSD. The bridge is a cloned interface which can be + modified by ifconfig and brconfig. It supports assigning an IP + address directly to the bridge (e.g. bridge0) instead of one of the + member interfaces, and can be used with tcpdump to inspect the + bridged packets. The code also supports spanning tree (802.1D) for + loop detection and link redundancy. Any pfil(9) packet filter can + be used to filter the bridged packets.</p> + </body> + + <help> + <task>Testing performance and functionality against the existing + bridge code. Testers welcome!</task> + </help> + </project> + + <project cat='arch'> + <title>ARM Support for TS-7200</title> + + <contact> + <person> + <name> + <given>John-Mark</given> + + <common>Gurney</common> + </name> + + <email>jmg@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.embeddedarm.com/epc/ts7200-spec-h.html"> + TS-7200 Board</url> + + <url + href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/jmg/arm&HIDEDEL=NO"> + Perforce Code Location</url> + + <url href="http://people.freebsd.org/~jmg/dmesg.ts7200">FreeBSD/arm + TS-7200 dmesg output</url> + </links> + + <body> + <p>I have been working on getting FreeBSD/arm running on the + TS-7200. So far the board boots, and has somewhat working ethernet + (some unexplained packet loss). I can netboot from a FreeBSD/i386 + machine, and I can also mount msdosfs's on CF.</p> + </body> + + <help> + <task>Figuring out why some small packets transmit with + error</task> + + <task>EP93xx identification information to properly attach various + onboard devices</task> + </help> + </project> + + <project cat='ports'> + <title>Update of the Linux userland infrastructure</title> + + <contact> + <person> + <name> + <given>Alexander</given> + + <common>Leidinger</common> + </name> + + <email>netchild@FreeBSD.org</email> + </person> + + <person> + <name> + <given>Emulation</given> + + <common>Mailinglist</common> + </name> + + <email>freebsd-emulation@FreeBSD.org</email> + </person> + </contact> + + <links> + </links> + + <body> + <p>The update to RedHat 8 as discussed in the last status report + went smoothly (just some minor glitches which got resolved + fast).</p> + + <p>As a next step a cleanup/streamlining and the possibility of + overriding the default Linux base is in progress. This depends on + changes which need at least one testrun on the ports build cluster, + so the final date for those changes depends upon the availability + of the cluster resources.</p> + </body> + + <help> + <task>Refactoring the common RPM code into bsd.rpm.mk.</task> + + <task>Determining which up-to-date Linux distribution to use as the + next default Linux base. Important criteria: + <ul> + <li>RPM based (to be able to use the existing + infrastructure)</li> + + <li>good track record regarding availability of security + fixes</li> + + <li>packages available from several mirror sites</li> + + <li>available for several hardware architectures (e.g. i386, + amd64, sparc64; Note: not all architectures have a working + linuxolator for their native bit with, but as long as there are + no userland bits available, no motivation regarding writing the + kernel bits will arise)</li> + </ul> + </task> + + <task>Moving the linuxolator userland to an up-to-date version (see + above).</task> + </help> + </project> + + <project cat='bin'> + <title>Pipe namespace added to portalfs</title> + + <contact> + <person> + <name> + <given>Diomidis</given> + + <common>Spinellis</common> + </name> + + <email>dds@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.spinellis.gr/blog/20050413/index.html" /> + </links> + + <body> + <p>A new sub-namespace, called pipe, has been added to portalfs. + The pipe namespace executes the named command, starting back at the + root directory. The command's arguments can be provided after the + command's name, by separating them with spaces or tabs. Files + opened for reading in the pipe namespace will receive their input + from the command's standard output; files opened for writing will + send the data of write operations to the command's standard input. + The pipe namespace allows us to perform scatter gather operations + without using temporary files, create non-linear pipelines, and + implement file views using symbolic links.</p> + </body> + </project> + + <project cat='kern'> + <title>Low-overhead performance monitoring for FreeBSD</title> + + <contact> + <person> + <name> + <given>Joseph</given> + + <common>Koshy</common> + </name> + + <email>jkoshy@FreeBSD.org</email> + </person> + </contact> + + <links> + <url + href="http://people.freebsd.org/~jkoshy/projects/perf-measurement"> + Project home page</url> + </links> + + <body> + <p>Many modern CPUs have on-chip performance monitoring counters + (PMCs) that can be used to count low-level hardware events like + instruction retirals, branch mispredictions, cache and TLB misses + and the like. PMC architectures and capabilities vary between CPU + vendors and between CPU generations from the same vendor, making + the creation of portable applications difficult. This project + attempts to provide a uniform API for applications to use, and the + necessary infrastructure to "virtualize" and manage the available + PMC hardware resources. The creation of performance analysis tools + that use this infrastructure is also part of the project's + goals.</p> + + <p>Work since the last status report:</p> + + <ul> + <li>Support for Intel + Pentium-Pro/Pentium-II/Pentium-III/Pentium-M/Celeron style PMCs + has been added.</li> + + <li>The Pentium-4/HTT machine dependent layer has been + overhauled.</li> + + <li>A Python language interface to the C library interface pmc(3) + has been written.</li> + + <li>Many bugs have been fixed and documentation has been + updated.</li> + </ul> + </body> + + <help> + <task>The code needs to be tested on Intel Pentium-M, Celeron, + Pentium II and Pentium Pro CPUs.</task> + </help> + </project> + + <project cat='proj'> + <title>GELI - GEOM class for providers encryption</title> + + <contact> + <person> + <name> + <given>Pawel Jakub</given> + + <common>Dawidek</common> + </name> + + <email>pjd@FreeBSD.org</email> + </person> + </contact> + + <links> + <url + href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/geom%5fclasses/sys/geom/eli&HIDEDEL=NO"> + Kernel module.</url> + + <url + href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/geom%5fclasses/sbin/geom/class/eli&HIDEDEL=NO"> + Userland configuration utility.</url> + </links> + + <body> + <p>GELI is a GEOM class used for GEOM providers encryption. I + decided to work on this, as I needed some feature, which cannot be + found in similar projects. Here is the list of features, I found + interesting:</p> + + <ul> + <li>makes use of crypto(9)</li> + + <li>if there is a crypto hardware available, GELI will run + cryptography on it automatically; if not, it starts dedicated + kernel thread and do crypto software work in there</li> + + <li>supports many cryptographic algorithms (AES, Blowfish, + 3DES)</li> + + <li>is able to take key components from many sources at once + (user entered passphrase, random bits from a file, etc.)</li> + + <li>allows to encrypt root partition</li> + + <li>user will be asked for the passphrase before root file system + is mounted</li> + + <li>uses "PKCS #5: Password-Based Cryptography Specification + Version 2.0" for user passphrase protection (optional)</li> + + <li>allows to use two independent keys (e.g. "user key" and + "company key")</li> + + <li>is fast</li> + + <li>GELI does simple sector-to-sector encryption</li> + + <li>allows to backup/restore Master Keys, so when user have to + quickly destroy keys, it is able to get the data back by + restoring keys from the backup</li> + + <li>provider can be configured at attach time to automatically + detach on last close (so user don't have to remember to detach + after unmounting file system)</li> + + <li>allows to attach provider with a random, one-time keys</li> + + <li>useful for swap partitions and temporary file systems</li> + </ul> + </body> + + <help> + <task>Code audit/review is more than welcome!</task> + </help> + </project> + + <project cat='doc'> + <title>FreeBSD Dutch Documentation Project</title> + + <contact> + <person> + <name> + <given>Remko</given> + + <common>Lodder</common> + </name> + + <email>remko@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.freebsd.org/doc/nl/books/handbook">FreeBSD + Dutch Handbook</url> + + <url href="http://www.evilcoder.org/freebsd_html/">FreeBSD Dutch + Handbook preview</url> + + <url href="http://www.evilcoder.org/content/section/6/39/">The + Project Page</url> + </links> + + <body> + <p>The FreeBSD Dutch Documentation Project is a ongoing project in + translating the English documentation to the Dutch language. + Currently we have translated almost the entire handbook, and more + to come. If you want to help out by review the Dutch documents, or + you want to help translating the remainders of the handbook or + other documents, feel free to contact me at + <a href="mailto:remko@FreeBSD.org">remko@FreeBSD.org</a> + </p> + </body> + + <help> + <task>Translate the English handbook, then review the Dutch + handbook</task> + + <task>Translate the English FAQ, then review the Dutch FAQ</task> + + <task>Translate the English Articles, then review the Dutch + Articles</task> + </help> + </project> + + <project cat='proj'> + <title>FreeBSD Java Project</title> + + <contact> + <person> + <name> + <given>Greg</given> + + <common>Lewis</common> + </name> + + <email>glewis@FreeBSD.org</email> + </person> + + <person> + <name> + <given>Alexey</given> + + <common>Zelkin</common> + </name> + + <email>phantom@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.FreeBSD.org/java/" /> + </links> + + <body> + <p>The FreeBSD Java Project released its initial support for JDK + 1.5.0 with patch set 1 "Sabretooth" in January. The initial release + featured support for both FreeBSD 5.3/i386 and 5.3/amd64. Since + then preliminary support for FreeBSD 4.11/i386 has been added and + several bug fixes have been made. Updates in the coming months will + add support for the browser plug in and Java Web Start, which were + not in the initial release.</p> + </body> + + <help> + <task>Volunteers to look into some serious problems with JDK 1.5.0 + on FreeBSD 4.x</task> + </help> + </project> + + <project cat='proj'> + <title>Common Address Redundancy Protocol - CARP</title> + + <contact> + <person> + <name> + <given>Max</given> + + <common>Laier</common> + </name> + + <email>mlaier@FreeBSD.org</email> + </person> + </contact> + + <contact> + <person> + <name> + <given>Gleb</given> + + <common>Smirnoff</common> + </name> + + <email>glebius@FreeBSD.org</email> + </person> + </contact> + + <links> + <url + href="http://www.freebsd.org/cgi/man.cgi?query=carp&manpath=FreeBSD+6.0-current" /> + + <url href="http://people.freebsd.org/~mlaier/CARP/" /> + </links> + + <body> + <p>CARP is an alternative to VRRP. In contrast to VRRP it has full + support for IPv6 and uses crypto to protect the advertisements. It + was developed by OpenBSD due to concerns that the HSRP patent might + cover VRRP and CISCO might defend its patent. CARP has, since then, + improved a lot over VRRP.</p> + + <p>CARP has been committed to HEAD and MFCed to RELENG_5. It will + be available in upcoming 5.4-RELEASE.</p> + + <p>Big thanks to all users who provided testing and reported bugs + to Max and Gleb. Daniel Seuffert has donated hardware to Max for + this project. Gleb's work was sponsored by + <a href="http://www.rambler.ru">Rambler</a> + + .</p> + </body> + + <help> + <task>Improve vlan(4) support. Test ng_eiface(4).</task> + + <task>Improve locking, consider removing interface layer.</task> + </help> + </project> + + <project cat='net'> + <title>netgraph(4) status report</title> + + <contact> + <person> + <name> + <given>Gleb</given> + + <common>Smirnoff</common> + </name> + + <email>glebius@FreeBSD.org</email> + </person> + </contact> + + <links> + <url + href="http://www.freebsd.org/cgi/man.cgi?query=ng_netflow&manpath=FreeBSD+6.0-current"> + ng_netflow(4)</url> + + <url + href="http://www.freebsd.org/cgi/man.cgi?query=ng_ipfw&manpath=FreeBSD+6.0-current"> + ng_ipfw(4)</url> + + <url href="http://people.freebsd.org/~glebius/totest/ng_nat/"> + ng_nat work in progress</url> + </links> + + <body> + <p>This report covers period since August 2004 until April + 2005.</p> + + <p>New nodes. Two new nodes have been added to base FreeBSD + distribution. ng_netflow(4) node, which implements NetFlow version + 5 accounting of IPv4 packets. ng_ipfw(4) node, which diverts + packets from ipfw(4) to netgraph(4) and back. A well known + ng_ipacct node has been added to ports tree.</p> + + <p>SMP. Nodes, which need to allocate unique names have been + protected with mutex in RELENG_5, and subr_unit allocator in HEAD. + Nodes, which need to run periodical jobs were reworked to use + mpsafe ng_callout() API. ng_tty(4) node has been overhauled to be + compatible with debug.mpsafenet=1. NetGraph ISR and callout are now + declared MPSAFE in HEAD.</p> + + <p>NetGraph flow control. Two nodes ng_ether(4) and ng_cisco(4) + have been improved to emit flow control messages to upstream node, + when state of link changes. New link failure detection method have + been introduced in ng_one2many(4) node - listening to these flow + control messages from downstream.</p> + </body> + + <help> + <task>more SMP testing of many nodes</task> + + <task>review locking of graph restructuring</task> + + <task>ng_nat node - an in-kernel natd(8)</task> + + <task>make ng_bridge(4) multithreaded</task> + </help> + </project> + + <project cat='kern'> + <title>drm</title> + + <contact> + <person> + <name> + <given>Eric</given> + + <common>Anholt</common> + </name> + + <email>anholt@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://r300.sourceforge.net/">ATI R300 DRI project</url> + </links> + + <body> + <p>A DRM update was finally committed to -current on 2005-04-15, + after jhb@ did the necessary fix to vm_mmap. New development + drivers were added for mach64 and r300 (see URL for info). The + nearly-finished code for savage and i915 were also added, but left + disconnected from the build. However, the most visible change is + likely the support for texture tiling, color tiling, and HyperZ on + Radeons, which (with updated userland) likely provide a 50-75% + framerate increase in many applications.</p> + </body> + + <help> + <task>Find someone with newbus knowledge to figure out why the i915 + won't attach to drmsub0.</task> + + <task>Finish porting the savage driver.</task> + + <task>Integrate busdma code from Tonnerre (NetBSD).</task> + </help> + </project> + + <project cat='kern'> + <title>Storage driver SMPng locking</title> + + <contact> + <person> + <name> + <given>Scott</given> + + <common>Long</common> + </name> + + <email>scottl@FreeBSD.org</email> + </person> + </contact> + + <links> + </links> + + <body> + <p>Several storage drivers have been taken out from under the Giant + mutex in the past few months. Thanks to sponsorship from + <a href="http://www.freebsdsystems.com">FreeBSD Systems, Inc</a> + + and + <a href="http://www.imp.ch">ImproWare, AG, Switzerland</a> + + , the LSI MegaRAID (AMR) and IBM/Adaptec ServeRAID (IPS) drivers + have been locked. SMPng locking is a key step in improving the + performance of system drivers in FreeBSD 5.x and beyond, and both + of these drivers are showing the benefits of this. FreeBSD 5.4 will + contains these improvements when it is released.</p> + + <p>Similar work is ongoing with the 3WARE Escalade (TWE) driver, + and preliminary patches have been made available to testers. I hope + to have this driver complete in time for the next FreeBSD + release.</p> + + <p>Unfortunately, most benefits can only be gained from pure block + storage drivers such as the ones mentioned here due to the SCSI + subsystem in FreeBSD (CAM) not be locked itself at this time. It is + possible, however, to lock a CAM sub-driver and bring the driver's + interrupt handler out from under Giant for a partial gain. The Sun + FAS366 SCSI driver (ESP) operates like this. Volunteers to lock + other drivers or to tackle locking CAM are gladly accepted, so + please contact me if you are interested.</p> + </body> + </project> + + <project cat='kern'> + <title>Filesystem journalling for UFS</title> + + <contact> + <person> + <name> + <given>Scott</given> + + <common>Long</common> + </name> + + <email>scottl@FreeBSD.org</email> + </person> + </contact> + + <links> + <url + href="http://repoman.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/scottl/ufsj" /> + </links> + + <body> + <p>It's time to bite the bullet and admit that fsck is no longer + scalable for modern storage capacities. While a healthy debate can + still be had on the merits and data integrity guarantees of + journalling vs. SoftUpdates, the fact that SoftUpdates still + requires a fsck to ensure consistency of the filesystem metadata + after an unclean shutdown means uptime is lost. While background + fsck is available, it saps system performance and stretched the + fsck time out to hours.</p> + + <p>Journalling provides a way to record transactions that might not + have fully been written to disk before the system crashed, and then + quickly recover the system back to a consistent state by replaying + these transactions. It doesn't guarantee that no data will be lost, + but it does guarantee that the filesystem will be back to a + consistent state after the replay is performed. This contrasts to + SoftUpdates that re-arranges metadata updates so that + inconsistencies are minimized and easy to recover from, though + recovery still requires the traditional full filesystem scan.</p> + + <p>Journalling is a key feature of many modern filesystems like + NTFS, XFS, JFS, ReiserFS, and Ext3, so the ground is well covered + and the risks for UFS/FFS are low. I'm aware that groups from CMU + and RPI have attempted similar work in the past, but unfortunately + the work is either very outdates, or I haven't had any luck in + contacting the groups. Is this absence, I've decided to work on + this project myself in hopes of having a functional prototype in + time for FreeBSD 6.0.</p> + + <p>The approach is simple and journals full metadata blocks instead + of just deltas or high-level operations. This greatly simplifies + the replay code at the cost of requiring more disk space for the + journal and more work within the filesystem to identify discreet + update points. An important design consideration is whether to make + the journal data and code compatible with the UFS2 filesystem, or + to start a new UFS3 derivative. Since the latter presents a very + high barrier to adoption for most people, I'm going to try to make + it a compatible option for UFS2. This means that the journal blocks + will likely appear as an unlinked file to legacy filesystem and + fsck code, and will be treated as such. This will allow seamless + fallback to using fsck, though once the unlinked journal data + blocks are reclaimed by fsck, the user will have to take action to + re-create the journal file again.</p> + + <p>One key piece of journalling is ensuring that each journal + transaction is fully written to disk before the associated metadata + blocks are written to the filesystem. I plan to adopt the buffer + 'pinning' mechanism from Alexander Kabaev's XFS work to assist with + this. This will allow the journalling subsystem fine-grained + control over which blocks get flushed to disk by the buffer daemon + without having to further complicate the UFS/FFS code. One + consideration is how Softupdates falls into this and whether it is + mutually exclusive of journalling or if it can help provide + transaction ordering functionality to the journal. Research here is + on-going.</p> + + <p>Some preliminary work can be found in Perforce in the + //depot/user/scottl/ufsj/... tree or at the URL provided. Hopefully + this will quickly accelerate.</p> + </body> + </project> + + <project cat='kern'> + <title>Status Report for FreeBSD ATA driver project</title> + + <contact> + <person> + <name> + <given>Søren</given> + + <common>Schmidt</common> + </name> + + <email>sos@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>ATA mkIII has been committed to -current after a couple of month + testing as patches post on -current and 5-stable. I will continue + to provide patches for 5-stable for those that need up-to-date ATA + support there.</p> + + <p>Here a short rehash of what mkIII brings:</p> + + <p>ATA is now fully modular so each part can be loaded/unloaded at + will to provided the wanted functionality.</p> + + <p>Much improved SATA support that support hotplug events on + controllers that support it (Promise, SiS, nVidia so far) ie the + system will automagically detect when SATA devices come and go and + add/delete device entries etc.</p> + + <p>Much improved ATA RAID support. The ata-raid driver has been + largely rewritten to take advantage of the features the improved + infrastructure provides, including composite ATA operations etc. + The rebuild functionality has been changed to rebuild on userland + reads, so a simple dd of the entire array will get it rebuild (what + atacontrol now does). This means that the resources used for this + can be better tailored to the actually usage pattern if needed. ATA + RAID now supports 10+ different RAID metadata formats, so most BIOS + defined ATA RAID arrays can be picked up and used. The number of + metadata formats that can be created from within FreeBSD is still + limited though and is not a high priority feature right now.</p> + + <p>The lowlevel infrastructure of the ATA driver has been refined + even further to support "strange" chipsets much more easily and in + most case transparent to the higher levels. This to easy ports to + new platforms where ATA controllers doesn't necessarily have the + x86 legacy layout.</p> + + <p>Lots of bug fixes and corrections all over the driver proper. + The rework of the infrastructure has revealed bugs and deficiencies + that has been fixed in the process of modulerising ATA and making + the infrastructure more generic, and hopefully easier to + understand.</p> + + <p>The work continues to keep ATA on top of new chipsets and other + advancements in the ATA camp. SATA ATAPI support is in the works + and so are support for NCA/TCQ (tags). Donations of unsupported + hardware is the way to get it supported as I'm way out of my budget + for new hardware for the next decade or so according to my wife + :)</p> + </body> + + <help> + <task>Lots of testing wanted, especially SATA and RAID + support</task> + </help> + </project> + + <project cat='proj'> + <title>GSHSEC - GEOM class for handling shared secret</title> + + <contact> + <person> + <name> + <given>Pawel Jakub</given> + + <common>Dawidek</common> + </name> + + <email>pjd@FreeBSD.org</email> + </person> + </contact> + + <links> + <url + href="http://www.freebsd.org/cgi/man.cgi?query=gshsec&apropos=0&sektion=0&manpath=FreeBSD+6.0-current&format=html"> + Manual page.</url> + </links> + + <body> + <p>GSHSEC is a GEOM class used for handling shared secret data + between multiple GEOM providers. For every write request, SHSEC + class splits the data using XOR operation with random data, so N-1 + providers gets just random data and one provider gets the data + XORed with the random data from the other providers. All of the + configured providers must be present in order to reveal the secret. + The class is already committed to HEAD and RELENG_5 branches.</p> + </body> + </project> + + <project cat='kern'> + <title>ATAPI/CAM</title> + + <contact> + <person> + <name> + <given>Thomas</given> + + <common>Quinot</common> + </name> + + <email>thomas@FreeBSD.org</email> + </person> + </contact> + + <links> + </links> + + <body> + <p>ATAPI/CAM integration with the new ATA (mkIII) framework is now + completed. ATAPI/CAM is now available as a loadable module + (atapicam.ko). It is also independent from the native ATAPI drivers + again, as was the case before mkIII.</p> + + <p>Thanks to Scott Long and Søren Schmidt for their + participation in the integration work.</p> + </body> + </project> + + <project cat='vendor'> + <title>twa driver</title> + + <contact> + <person> + <name> + <given>Vinod</given> + + <common>Kashyap</common> + </name> + + <email>vkashyap at amcc.com</email> + </person> + </contact> + + <links> + <url href="http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/twa/"> + source code</url> + + <url + href="http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/modules/twa/"> + source code</url> + </links> + + <body> + <p>A newly re-architected twa(4) driver was committed to 6 -CURRENT + on 04/12/2005. Highlights of this release are:</p> + + <ol> + <li>The driver has been re-architected to use a "Common Layer" + (all tw_cl* files), which is a consolidation of all + OS-independent parts of the driver. The FreeBSD OS specific + portions of the driver go into an "OS Layer" (all tw_osl* files). + This re-architecture is to achieve better maintainability, + consistency of behavior across OS's, and better portability to + new OS's (drivers for new OS's can be written by just adding an + OS Layer that's specific to the OS, by complying to a "Common + Layer Programming Interface (CLPI)" API. If there's interest in + porting the 3ware driver to any other OS, you may contact ctchu + at amcc.com to get a copy of the CLPI specifications.</li> + + <li>The driver takes advantage of multiple processors. It does + not need to be Giant protected anymore.</li> + + <li>The driver has a new firmware image bundled, the new features + of which include Online Capacity Expansion and multi-lun support, + among others. More details about 3ware's 9.2 release can be found + here: + <a + href="http://www.3ware.com/download/Escalade9000Series/9.2/9.2_Release_Notes_Web.pdf"> + http://www.3ware.com/download/Escalade9000Series/9.2/9.2_Release_Notes_Web.pdf</a> + </li> + </ol> + </body> + </project> + + <project cat='net'> + <title>IPv6 Support for IPFW</title> + + <contact> + <person> + <name> + <given>Brooks</given> + + <common>Davis</common> + </name> + + <email>brooks@FreeBSD.org</email> + </person> + </contact> + + <links> + <url + href="http://lists.freebsd.org/pipermail/cvs-all/2005-April/116671.html" /> + </links> + + <body> + <p>In April 18th, I committed support for IPv6 to IPFW. This + support was written by two student of Luigi's, Mariano Tortoriello + and Raffaele De Lorenzo. I updated it to use PFIL_HOOKS and fixed a + few minor issues. As of this commit, IP6FW should be considered + deprecated in favor of IPFW. It should be possible to MFC this + change to 5.x, but that is not currently planned.</p> + </body> + + <help> + <task>Testing.</task> + + <task>IP6FW to IPFW migration guide.</task> + + <task>Patches relative to 5-STABLE.</task> + </help> + </project> + + <project cat='net'> + <title>Removable interface improvements.</title> + + <contact> + <person> + <name> + <given>Brooks</given> + + <common>Davis</common> + </name> + + <email>brooks@FreeBSD.org</email> + </person> + </contact> + + <links> + <url + href="http://people.freebsd.org/~brooks/pubs/eurobsdcon2004/" /> + + <url href="http://www.freebsd.org/projects/dingo/" /> + </links> + + <body> + <p>This project is an attempt to clean up handling of network + interfaces in order to allow interfaces to be removed reliably. + Current problems include panics if Dummynet is delaying packets to + an interface when it is removed.</p> + + <p>I am currently working to remove struct ifnet's from device + driver structures to allow them to be managed properly upon device + removal. I believe I have removed all known instances of casting a + struct ifnet pointer to something else (except that that are just + magic values and not real struct ifnets.) I will begin committing + these changes to the tree shortly and will then add a new function + if_alloc() that will allocate struct ifnets. if_detach() will be + modified to destroy them.</p> + </body> + </project> + + <project cat='kern'> + <title>cpufreq</title> + + <contact> + <person> + <name> + <given>Nate</given> + + <common>Lawson</common> + </name> + + <email>njl</email> + </person> + </contact> + + <links> + <url + href="http://www.freebsd.org/cgi/man.cgi?query=cpufreq&manpath=FreeBSD+6.0-current&format=html"> + cpufreq man page</url> + </links> + + <body> + <p>The cpufreq project was committed to 6-CURRENT in early February + and has undergone bugfixes and updates. It will soon be MFCd to + 5-STABLE.</p> + + <p>The cpufreq driver provides a unified kernel and user interface + to CPU frequency control drivers. It combines multiple drivers + offering different settings into a single interface of all possible + levels. Users can access this interface directly via sysctl(8), by + indicating to power_profile that it should switch settings when the + AC line state changes, or by using powerd(8).</p> + + <p>For example, an absolute driver offering frequencies of 1000 Mhz + and 750 Mhz combined with a relative driver offering settings of + 100% and 50% would result in cpufreq providing levels of 1000, 750, + 500, and 375 Mhz.</p> + + <p>Colin Percival helped with powerd(8), which provides automatic + control of CPU frequencies. The adaptive mode is especially + interesting since it attempts to respond to changes in system load + while reducing power consumption.</p> + + <p>Current hardware drivers include acpi_perf (ACPI CPU performance + states), est (Intel Enhanced SpeedStep for Pentium-M), ichss + (Intel's original SpeedStep for ICH), and powernow (AMD Powernow! + K7 and K8 support). Other drivers for relative hardware include + acpi_throttle (ACPI CPU throttling) and p4tcc (Pentium 4 Thermal + Control Circuitry)</p> + + <p>Thanks to Bruno Ducrot for the powernow driver, Colin Percival + for the est driver, and the many testers who have sent in + feedback.</p> + </body> + + <help> + <task>We'd appreciate someone with a Transmeta CPU converting the + existing longrun driver to the cpufreq framework. It would also be + good if someone wrote a VIA Longhaul driver. See the Linux + arch/i386/kernel/cpu/cpufreq directory for examples.</task> + + <task>Various other architectures, including ARM, have CPU power + control that could be implemented as a cpufreq driver.</task> + + <task>The powerd(8) algorithm is rather simple and we'd appreciate + more help in testing it and alternative algorithms with various + workloads. The -v flag causes powerd to report frequency + transitions and print a summary of total energy used upon + termination. This should help testers profile their + algorithms.</task> + </help> + </project> + + <project cat='net'> + <title>Move ARP out of routing table</title> + + <contact> + <person> + <name> + <given>Qing</given> + + <common>Li</common> + </name> + + <email>qingli@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://people.freebsd.org/~qingli/">containing the + patch</url> + </links> + + <body> + <p>I have finished the basic functionality for both IPv4 and IPv6. + The userland utilities ("arp" and "ndp") have been updated. I have + tested the changes with "make buildworld". I have been testing the + new code in a production environment and things appear to be + stable. Gleb Smirnoff (glebius@FreeBSD.org) has provided review + comments and I have incorporated these feedback into the patch. I + have discussed the IPv6 changes with two of the core KAME + developers during the last IETF meeting in March 2005. They + indicated that these changes may result in divergence from the KAME + project but that is not necessarily a bad thing.</p> + </body> + + <help> + <task>I am waiting for review feedback from my mentor Andre. I need + locking experts to help me fix my giant-lock shortcut. I am hoping + to send out the code for wider review soon.</task> + </help> + </project> + + <project cat='net'> + <title>Support for telephone hardware (aka Zaptel)</title> + + <contact> + <person> + <name> + <given>Maxim</given> + + <common>Sobolev</common> + </name> + + <email>sobomax@FreeBSD.org</email> + </person> + + <person> + <name> + <given>Oleksandr</given> + + <common>Tymoshenko</common> + </name> + + <email>gonzo@pbxpress.com</email> + </person> + + <person> + <name> + <given>Max</given> + + <common>Khon</common> + </name> + + <email>fjoe@FreeBSD.org</email> + </person> + </contact> + + <links> + <url + href="http://www.digium.com/index.php?menu=hardware_products" /> + </links> + + <body> + <p>During the last 2 months lot of progress has been made. Existing + support for TDM400 (FXO/FXS) has been significantly improved. + Drivers for PRI and BRI cards have been added and now should be + considered beta-quality.</p> + </body> + + <help> + <task>More testing of PRI/BRI drivers.</task> + + <task>Add support for channelized DS3 card(s).</task> + </help> + </project> + + <project cat='ports'> + <title>FreshPorts</title> + + <contact> + <person> + <name> + <given>Dan</given> + + <common>Langille</common> + </name> + + <email>dan@langille.org</email> + </person> + </contact> + + <links> + <url href="http://www.freshports.org/">FreshPorts</url> + </links> + + <body> + <p>This is the first status report for FreshPorts. FreshPorts + started in early 2000 and now contains over 170,000 commits. + FreshPorts is primarily concerned with port commits, but actually + processes and records all commits to the FreeBSD source tree. Its + sister site, + <a href="http://www.freshsource.org/">FreshSource</a> + + uses the same database as FreshPorts but has a wider reporting + scope. In recent months, FreshPorts has been enhanced to process + and include + <a href="http://www.vuxml.org/freebsd/">VuXML</a> + + information. In addition, RESTRICTED and NO_CDROM have been added + to list of things that FreshPorts keeps track of. For unmaintained + ports, we recently added this message: + <p> + <em>There is no maintainer for this port. + <br /> + + Any concerns regarding this port should be directed to the + FreeBSD Ports mailing list via ports@FreeBSD.org</em> + </p> + + FreshPorts, with direct and indirect support from the FreeBSD + community, continues to evolve and to provide a great tool for + users and developers alike.</p> + </body> + + <help> + <task>Provide a copy/paste method for updating watch lists</task> + + <task>improvement of query times for "People watching this port, + also watch"</task> + + <task>pagination of commits within a port</task> + + <task>pagination of watch lists</task> + + <task>create an RSS feed for individual watch lists</task> + </help> + </project> + + <project cat='misc'> + <title>BSDCan</title> + + <contact> + <person> + <name> + <given>Dan</given> + + <common>Langille</common> + </name> + + <email>dan@langille.org</email> + </person> + </contact> + + <links> + <url href="http://www.bsdcan.org/" /> + </links> + + <body> + <p>BSDCan made a strong debut in + <a href="http://www.bsdcan.org/2004/">2004</a> + + . The favorable reception gave us a strong incentive for + <a href="http://www.bsdcan.org/2005/">2005</a> + + . We have been rewarded with a very interesting + <a href="http://www.bsdcan.org/2005/schedule.php">program</a> + + and a higher rate of registrations. Percentage-wise, we have more + Europeans than last year as they have decided that the trip across + the Atlantic is worth taking. We know they won't be disappointed. + See you at BSDCan 2005!</p> + </body> + + <help> + <task>volunteers needed for the conference</task> + </help> + </project> + + <project cat='ports'> + <title>Ports Collection</title> + + <contact> + <person> + <name> + <given>Mark</given> + + <common>Linimon</common> + </name> + + <email>linimon@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.freebsd.org/ports/">The FreeBSD ports + collection</url> + + <url href="http://portsmon.firepipe.net/index.html">FreeBSD ports + monitoring system</url> + + <url href="http://www.freebsd.org/portmgr/index.html">The FreeBSD + Ports Management Team</url> + </links> + + <body> + <p>As this report was being written, the 5.4 release was + ongoing.</p> + + <p>A new charter for the Ports Management (portmgr) team was + approved by core and has been posted at the URL above. In addition, + two other new pages describe the policies of the team, and the + range of QA activities both during and between releases.</p> + + <p>Due to being absent from email discussions for some time, Oliver + Eikemeier (eik) was moved to non-voting status on portmgr.</p> + + <p>We have added several new and very active committers recently; + this is helping us to keep the PR count low even with the large + numbers of new ports that have been added.</p> + + <p>Several more iterations of infrastructure changes have been + tested on the cluster and committed; see /usr/ports/CHANGES for + details.</p> + + <p>Updates have occurred to x.org, GNOME, KDE, and perl.</p> + + <p>There have been some updates to the Porter's Handbook, but more + sections are still in need of updates to include recent changes in + practices.</p> + + <p>The ports collection now contains almost 12,750 ports.</p> + </body> + + <help> + <task>Further progress has been made in cracking down on ports that + install files outside the approved directories and/or do not + deinstall cleanly (see "Extra files not listed in PLIST" on + <a href="http://pointyhat.freebsd.org/errorlogs/">pointyhat</a> + + ) and this will remain a focus area. We appreciate everyone who has + sent in PRs or committed fixes.</task> + + <task>Demand for new features and revisions for bsd.port.mk is + still very high and the portmgr team is trying to work through them + all.</task> + + <task>We still have a large number of PRs that have been assigned + to committers for some time (in fact, they constitute the + majority). One goal of portmgr in the coming months is to try to + reduce this number, and we would like to ask our committers to help + us out as much as possible.</task> + </help> + </project> + + <project cat='arch'> + <title>PowerPC Port</title> + + <contact> + <person> + <name> + <given>Peter</given> + + <common>Grehan</common> + </name> + + <email>grehan@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>Progress continues. X.Org 6.8.1 server has been up and running + on a number of different Macs, and the work is being merged into + 6.8.2. There have been successful installs on Mac Minis</p> + </body> + </project> + + <project cat='vendor'> + <title>OpenBSD packet filter - pf</title> + + <contact> + <person> + <name> + <given>Max</given> + + <common>Laier</common> + </name> + + <email>mlaier@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://pf4freebsd.love2party.net/">pf4FreeBSD + Homepage</url> + + <url href="http://people.freebsd.org/~mlaier/pf37/">pf 3.7 patches</url> + </links> + + <body> + <p>OpenBSD is about to release + <a href="http://www.openbsd.org/37.html">version 3.7</a> + + . There are + <a href="http://people.freebsd.org/~mlaier/pf37/">patches</a> + + available to catch up with the development done in OpenBSD 3.6 and + 3.7. These patches are in an early stage, but ready for testing, + please help.</p> + + <p>Otherwise there was not much activity on pf, as it already is + quite stable. Other work, such as CARP and if_bridge are having + impact on pf in FreeBSD however, please see the respective + reports.</p> + </body> + + <help> + <task>Alpha/Betatesting of the 3.7 import</task> + + <task>Testing with if_bridge</task> + </help> + </project> + + <project cat='bin'> + <title>libthread</title> + + <contact> + <person> + <name> + <given>David</given> + + <common>Xu</common> + </name> + + <email>davidxu@FreeBSD.org</email> + </person> + </contact> + + <links> + </links> + + <body> + <p>libthread is a pure 1:1 threading library, it had stayed in my + perforce branch for a long time, recent it was imported into source + tree and replaced libthr. The purpose of the work is to improve 1:1 + threading on FreeBSD, the library is designed in mind that simplest + is best, currently it can run almost all of the applications + libpthread can run, but gives you better SMP performance. The + library size is smaller than libpthread.</p> + + <p>Currently it supports i386, AMD64, sparc64 and ia64 and may + support alpha, powerpc and arm. I didn't do many tests on sparc64 + and ia64, I only tested it on FreeBSD cluster machines. For i386, I + always used LDT, but know that Peter committed GDT code, and now + there is no 8191 threads limitation anymore.</p> + + <p>libthread_db was updated to support debugging the new libthr. It + is an assistant library used by gdb to debug threaded process, that + understands internal detail of thread libraries. I have improved it + a bit to support event reports for libthr, currently it can report + thread creation and death events. That means a thread that was + created and died will be reported to the user regardless if you are + tracking it or not.</p> + </body> + + <help> + <task>I am working on thread creation performance, currently it + needs considerable number of libc functions and syscalls to create + a thread, I would like to introduce a syscall to create a thread in + atomically. That means one syscall will setup thread entry, tls, and + signal mask and PTHREAD_SCOPE_PROCESS/SYSTEM; in future maybe even + CPU affinity masks, when userland entry code is executed, the + thread is already fully setup.</task> + + <task>Process shareable synchronization objects. In Current FreeBSD + does not support this specification. The idea about the shareable + mutex and others is like other systems did, one can use mmap() to + create a shared memory page, and put a pthread synchronization + object in the page, multiple processes use the shared object to + control resource access. I am not working on it, if someone is + interested, please let me know.</task> + </help> + </project> + + <project cat='kern'> + <title>Coverity Code Analysis</title> + + <contact> + <person> + <name> + <given>Sam</given> + + <common>Leffler</common> + </name> + + <email>sam@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.coverity.com/" /> + </links> + + <body> + <p>There has been an ongoing effort to review the kernel source + code using Coverity's source code analysis tools + (http://www.coverity.com). These tools check for a variety of + problems such as null pointer dereference, use-after-free of + allocated variables, invalid array references, etc. This work is a + joint project between FreeBSD and Coverity.</p> + + <p>Two passes have been completed over the 6-current kernel source + code base and all significant problems have been corrected. These + runs were done in February and March of this year. A few reports of + minor problems await response from outside groups and will be + resolved in time for the first 6.x release. Another analysis run + over the kernel will happen soon. We are looking for a way to use + these tools on a regular basis as they have been helpful in + improving the code base.</p> + + <p>Thanks to Coverity for their help and especially Ted Unangst. + Several developers have been especially helpful in resolving + reports: Poul-Henning Kamp, David Schultz, Pawel Jakub Dawidek, + George V. Neville-Neil, and Matthew Dodd.</p> + </body> + </project> + + <project cat='net'> + <title>Wireless Networking Support</title> + + <contact> + <person> + <name> + <given>Sam</given> + + <common>Leffler</common> + </name> + + <email>sam@FreeBSD.org</email> + </person> + </contact> + + <links> + </links> + + <body> + <p>Several new drivers by by Damien Bergamini were brought into the + tree: iwi, ipw, ral, and ural.</p> + + <p>WPA-PSK support for the ndis driver was contributed by Arvind + Srinivasa.</p> + + <p>A new tx rate control algorithm for the ath driver was + contributed by John Bicket. It will become the default algorithm + shortly.</p> + + <p>Work on multi-bss support is going on outside the cvs tree. A + presentation on this work will be given at BSDCan 2005 and the + slides for the talk will be made available after.</p> + </body> + + <help> + <task>Drivers other than ath and ndis need updates to support the + new security protocols.</task> + + <task>hostapd needs work to support the IAPP and 802.11i + preauthentication protocols (these are simple conversions of + existing Linux code).</task> + + <task>The OpenBSD dhclient program has been ported but needs a + developer that will maintain it once it is brought into cvs.</task> + </help> + </project> + + <project cat='kern'> + <title>Many subdirs for UFS</title> + + <contact> + <person> + <name> + <given>David</given> + + <common>Malone</common> + </name> + + <email>dwmalone@FreeBSD.org</email> + </person> + </contact> + + <links> + <url + href="http://groups-beta.google.com/group/muc.lists.freebsd.fs/browse_frm/thread/a36d1143d695287e/40cad00cf2c0823b?hl=en#40cad00cf2c0823b"> + Thread on freebsd-fs</url> + </links> + + <body> + <p>I'm currently looking at the limit on the number of + subdirectories a directory can have in UFS. There is currently a + limit of 32K subdirectories because of the 16 bit link count field + in both struct stat and the on-disk inode format. The thread above + shows that dirhash provides acceptable performance for directories + with 100k subdirectories using a prototype patch. Two options for + allowing many subdirectories seem to exist: changing the link + counting scheme for directories and expanding the link count field. + The prototype patch implements the first scheme and there are plans + to investigate the second scheme (which may require an ABI + change).</p> + </body> + </project> + + <project cat='misc'> + <title>IMUNES - a FreeBSD based kernel-level network topology + emulator</title> + + <contact> + <person> + <name> + <given>Miljenko</given> + + <common>Mikuc</common> + </name> + + <email>miljenko@tel.fer.hr</email> + </person> + + <person> + <name> + <given>Marko</given> + + <common>Zec</common> + </name> + + <email>zec@tel.fer.hr</email> + </person> + </contact> + + <links> + <url href="http://www.imunes.net/" /> + </links> + + <body> + <p>IMUNES is a scalable kernel-level network topology emulator + based on FreeBSD. In IMUNES each virtual node operates on its + private instance of network stack state variables, such as routing + tables, interface addresses, sockets, ipfw rules etc. Most if not + all existing FreeBSD application binaries, including routing + protocol daemons such as quagga or XORP, can run unmodified within + the context of virtual nodes with no noticeable performance + penalty. Complex network topologies can be constructed by + connecting the virtual nodes through netgraph-based link-layer + paths. A GUI tool allows for simple and intuitive network topology + specification, deployment and management. The current version of + IMUNES is based on FreeBSD 4.11-RELEASE and supports IPv4.</p> + </body> + </project> + + <project cat='arch'> + <title>XenFreeBSD - FreeBSD on Xen</title> + + <contact> + <person> + <name> + <given>Kip</given> + + <common>Macy</common> + </name> + + <email>kmacy@fsmware.com</email> + </person> + </contact> + + <links> + <url href="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/">Xen + project page</url> + + <url href="http://xen.bkbits.net/">Xen changeset logs</url> + </links> + + <body> + <p>FreeBSD 5.3 runs on the stable and the development branches of + xen and is now checked into both trees. Over the next couple of + weeks I will be adding improvements for better batching of page + table updates and SMP support.</p> + </body> + + <help> + <task>FreeBSD support for running as Domain 0, i.e. running as the + hosting operating system.</task> + + <task>FreeBSD support for VM checkpoint and migration.</task> + </help> + </project> + + <project cat='net'> + <title>Dingo</title> + + <contact> + <person> + <name> + <given>George</given> + + <common>Neville-Neil</common> + </name> + + <email>gnn@neville-neil.com</email> + </person> + </contact> + + <links> + <url href="http://people.freebsd.org/~gnn/Dingo/notebook/60.html"> + Project page (out of date)</url> + + <url href="http://zoo.unixdaemons.com/index.php?blog=7">Blog + covering test framework</url> + </links> + + <body> + <p>On the protocol conformance tool I have finally made some + progress getting a scriptable packet library using libnet, and + SWIG. This will hopefully become a port that can then be used to do + conformance testing on protocol stack changes. Qing Li has + separately taken up the ARP rewrite and that will be taken out of + the Dingo project pages.</p> + </body> + + <help> + <task>Many :-)</task> + </help> + </project> + + <project cat='kern'> + <title>Interrupt Latency</title> + + <contact> + <person> + <name> + <given>Warner</given> + + <common>Losh</common> + </name> + + <email>imp@FreeBSD.org</email> + </person> + </contact> + + <links> + </links> + + <body> + <p>I've setup a test system to measure interrupt latency on FreeBSD + 5.3 and current. So far I've measured the baseline latency for a + 300MHz embedded cyrix based single board computer. I've tried a + number of different strategies to optimize the interrupt path. Most + of these strategies resulted in some improvement of the time it + takes to get from the start of the interrupt servicing to the + driver's ISR. These improvements turned out to be about 1-2% of the + processing times on this single board computer, but a wash on + faster machines. However, the time between when the interrupt + should happen, and when FreeBSD starts to service the interrupt is + the dominant factor in these measurements. Despite the fact that + these are fast interrupt handlers (so the scheduler is out of the + loop), I routinely see average latencies of 18us, with large + variations (on the order of 5us standard deviation).</p> + </body> + + <help> + <task>I need to measure the latencies with 4.x and current to + characterize the differences more precisely. I'm especially + interested in the effects on interrupt latency that the elimination + of mixed mode will cause.</task> + + <task>I need to characterize different parts of our ISR routines to + see if some of the variation I've seen so far can be reduced by + improved coding techniques.</task> + + <task>I need to re-run my tests with 5.4 and summarize my results + in a paper.</task> + </help> + </project> + + <project cat='kern'> + <title>Infrastructure Cleanup</title> + + <contact> + <person> + <name> + <given>Warner</given> + + <common>Losh</common> + </name> + + <email>imp@FreeBSD.org</email> + </person> + + <person> + <name> + <given>Takahashi</given> + + <common>Yoshihiro</common> + </name> + + <email>nyan@FreeBSD.org</email> + </person> + </contact> + + <links> + </links> + + <body> + <p>Unglamorous cleanup of the code base continues. The focus of + recent efforts have been to reduce the number of machine #ifdefs + that are in the machine independent code. In addition, we're also + trying to increase code sharing between pc98 and i386 ports and + reduce the number of #ifdef PC98 instances in the tree.</p> + + <p>In addition, a number of cleanup tasks are underway for + different parts of the kernel that are more complicated than + necessary. Recently, the pccard code's allocation routines were + simplified to reassign ownership of resources more directly than + before. The search is on for other areas that can benefit from + cleanup.</p> + </body> + + <help> + <task>On pc98, there's no such thing as an ISA bus. It is desirable + to move to having cbus appear in the probe messages. This would + also allow for additional segregation of pc98 specific code in the + drivers and eliminate many ifdefs. Ideally, isa and cbus would + share a common newbus ancestor class so their similarities can be + exploited (they both have PNPBIOS enumeration methods, for + example).</task> + + <task>cbus devices can have complicated resources. There's support + for vectors of resources. Yet there's no support for populating a + vector of resources from the plug and play information. Doing so + would help the complex world of pc98 a lot, and the odd edge cases + in i386 (floppy, ata) a little.</task> + + <task>The hints mechanism provides a way to associate hardware with + drivers and resource that would otherwise be completely unknown to + the system. A refinement in the hints mechanism to allow matching + of driver instances to resources is desirable. This would allow one + to hardwire sio0 to 0x2f8, even when the serial device in the plug + and play resource list (or acpi resource list) is listed second. A + further refinement could also be wiring sio0 to "port B" as defined + by acpi or some other enumeration method. Chances are good that + these seemingly related concepts may need separate implementations + due to the decision points for unit assignment.</task> + + <task>Pccard, cardbus and usb probe their devices after interrupts + are enabled. It would be desirable to hook into new kernel APIs to + allow the mounting of root to be put off until those systems know + that they are done with their initial probe of the devices present + at boot.</task> + </help> + </project> + + <project cat='misc'> + <title>FreeBSD Security Officer and Security Team</title> + + <contact> + <person> + <name> + <given>Security</given> + + <common>Officer</common> + </name> + + <email>security-officer@FreeBSD.org</email> + </person> + + <person> + <name> + <given>Security</given> + + <common>Team</common> + </name> + + <email>security-team@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.freebsd.org/security/" /> + + <url + href="http://www.freebsd.org/administration.html#t-secteam" /> + + <url href="http://vuxml.freebsd.org/" /> + </links> + + <body> + <p>In January 2005, Warner Losh (Security Officer Emeritus) stepped + down from the FreeBSD Security Team in order to better devote his + time to other projects. In March, Colin Percival was named as a + second Deputy Security Officer, joining Dag-Erling Smørgrav in + that position. The current Security Team membership is published on + the web site.</p> + + <p>So far in 2005, four security advisories have been issued + concerning problems in the base system of FreeBSD, three of which + were specific to FreeBSD. The Vulnerabilities and Exposures Markup + Language (VuXML) document has continued to be updated by the + Security Team and the Ports Committers documenting new + vulnerabilities in the FreeBSD Ports Collection. As of April 17, + 127 entries have been added in 2005 bringing the FreeBSD VuXML file + up to a total of 422 entries.</p> + + <p>In the past months both the + <a href="http://vuxml.FreeBSD.org/">VuXML web site</a> + + and the + <a href="http://www.FreshPorts.org/">FreshPorts</a> + + VuXML integration have been improved. The VuXML web site has had a + face lift and, among other things, each package now has a separate + web page which lists all documented vulnerabilities for the + particular package. + <a href="http://cve.mitre.org/">CVE</a> + + information is now also included directly on the VuXML web + site.</p> + + <p>Finally, the first few months of 2005 also saw FreeBSD 4.8 -- + the first release to be offered "extended support" -- reach its + designated End of Life. The currently supported releases are + FreeBSD 4.10, 4.11, and 5.3.</p> + </body> + </project> + + <project cat='proj'> + <title>FreeBSD Release Engineering</title> + + <contact> + <person> + <name> + <given>RE</given> + <common>Team</common> + </name> + <email>re@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://www.freebsd.org/releng" /> + </links> + + <body> + <p>FreeBSD 4.11, the final formal release of the 4.x series, was + released on 25 Jan 2005. Many thanks to the all of the developers + and users over the past 5 years who made it successful. While no + more releases are planned, the security team will continue to + support it through security update patches until 2007. Developers + are also free to commit bug fixes and low-risk features to the + RELENG_4 branch for the foreseeable future.</p> + <p>FreeBSD 5.4 is going through its final release candidate stages + and is expected to be released in late April. Its focus is mostly + bug fixes and minor feature and performance improvements, so it is + an excellent target for those looking to upgrade from previous + versions or to give FreeBSD a try for the first time. FreeBSD 5.5 + will be release in about 4-6 months after 5.4.</p> + <p>FreeBSD 6.0 is rapidly approaching also. In contrast to FreeBSD + 5.0, the goal is to take a more incremental approach to major + changes, and not wait for years to get as many features in as + possible. FreeBSD 6.0 will largely be an evolutionary change from + the 5.x series, with the largest changes centered around + multi-threading and streamlining the filesystem and device layers. + Feature freeze and code freeze for 6.0 are coming up in May and + June, and we hope to have 6.0 stable and ready for release in July + or August.</p> + <p>The release engineering team has also started doing monthly + informal snapshots of the 6-CURRENT and 5-STABLE trees. These are + intended to increase the exposure of new features and get more + users involved in testing and providing feedback. Snapshots can + be found at <a href="http://www.freebsd.org/snapshots"> + http://www.freebsd.org/snapshots</a>.</p> + </body> + </project> + + <project cat='net'> + <title>New Wireless Drivers</title> + + <contact> + <person> + <name> + <given>Damien</given> + + <common>Bergamini</common> + </name> + + <email>damien@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://ipw2100.sourceforge.net/firmware.php?fid=4" /> + + <url href="http://ralink.rapla.net/" /> + </links> + + <body> + <p>Four new wireless drivers were imported:</p> + + <p> + <em>ipw</em> + + : driver for Intel PRO/Wireless 2100 adapters (MiniPCI). + <br /> + + <em>iwi</em> + + : driver for Intel PRO/Wireless 2200BG/2225BG/2915ABG adapters (PCI + or MiniPCI). + <br /> + + <em>ral</em> + + : driver for Ralink RT2500 wireless adapters (PCI or CardBus). + <br /> + + <em>ural</em> + + : driver for Ralink RT2500USB wireless USB 2.0 adapters.</p> + + <p>The ipw and iwi drivers require firmwares to operate. + <br /> + + These firmwares can't be redistributed with the base system due to + license restrictions. + <br /> + + See firmware licensing terms here: + <a href="http://ipw2100.sourceforge.net/firmware.php?fid=4"> + http://ipw2100.sourceforge.net/firmware.php?fid=4</a> + + . + <br /> + </p> + + <p>Ports which include the firmware images as well as the firmware + loader are being worked on. + <br /> + + A list of adapters supported by ral and ural can be found here: + <a href="http://ralink.rapla.net/">http://ralink.rapla.net/</a> + + .</p> + </body> + + <help> + <task>Create ports for ipw and iwi firmwares.</task> + + <task>Add IBSS support to iwi.</task> + + <task>Add WPA (802.11i) support to ipw and iwi.</task> + + <task>Add hardware encryption (WEP, TKIP and CCMP) support in ral + and ural.</task> + + <task>Add automatic rate adaptation support to ural.</task> + </help> + </project> +</report> + |