diff options
Diffstat (limited to 'en/news/status/report-2005-01-2005-03.xml')
| -rw-r--r-- | en/news/status/report-2005-01-2005-03.xml | 2147 |
1 files changed, 0 insertions, 2147 deletions
diff --git a/en/news/status/report-2005-01-2005-03.xml b/en/news/status/report-2005-01-2005-03.xml deleted file mode 100644 index b9b43ada34..0000000000 --- a/en/news/status/report-2005-01-2005-03.xml +++ /dev/null @@ -1,2147 +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"> - -<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/doc/en_US.ISO8859-1/articles/contributors/staff-listing.html#STAFF-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> - |