aboutsummaryrefslogtreecommitdiff
path: root/en/news/status/report-2005-01-2005-03.xml
diff options
context:
space:
mode:
Diffstat (limited to 'en/news/status/report-2005-01-2005-03.xml')
-rw-r--r--en/news/status/report-2005-01-2005-03.xml2143
1 files changed, 0 insertions, 2143 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 2fc9beb633..0000000000
--- a/en/news/status/report-2005-01-2005-03.xml
+++ /dev/null
@@ -1,2143 +0,0 @@
-<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&amp;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&amp;HIDEDEL=NO">
- Kernel module.</url>
-
- <url
- href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/geom%5fclasses/sbin/geom/class/eli&amp;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&amp;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&amp;manpath=FreeBSD+6.0-current">
- ng_netflow(4)</url>
-
- <url
- href="http://www.freebsd.org/cgi/man.cgi?query=ng_ipfw&amp;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&#248;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&amp;apropos=0&amp;sektion=0&amp;manpath=FreeBSD+6.0-current&amp;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&#248;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&amp;manpath=FreeBSD+6.0-current&amp;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&#248;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>
-