diff options
Diffstat (limited to 'en/news/status/report-2004-01-2004-02.xml')
| -rw-r--r-- | en/news/status/report-2004-01-2004-02.xml | 865 |
1 files changed, 0 insertions, 865 deletions
diff --git a/en/news/status/report-2004-01-2004-02.xml b/en/news/status/report-2004-01-2004-02.xml deleted file mode 100644 index 325b7971f5..0000000000 --- a/en/news/status/report-2004-01-2004-02.xml +++ /dev/null @@ -1,865 +0,0 @@ -<!-- $FreeBSD: www/en/news/status/report-jan-2004-feb-2004.xml,v 1.4 2004/04/07 11:27:47 phantom Exp $ --> -<report> - <date> - <month>January-February</month> - <year>2004</year> - </date> - - <section> - <title>Introduction:</title> - - <p>2004 started with another exciting two months for the project. - FreeBSD 5.2 was released in early January and then quickly followed - in February with the 5.2.1 bug-fix release. Looking forward, we - are expecting a late-April release date for FreeBSD 4.10, and - mid-summer date for FreeBSD 5.3. And don't forget to support the - FreeBSD vendors and developers by buying a copy of the latest CD - or DVD sets.</p> - - <p>Thanks,</p> - - <p>Scott Long</p> - </section> - - <project> - <title>Disk and device I/O</title> - - <contact> - <person> - <name> - <given>Poul-Henning</given> - <common>Kamp</common> - </name> - <email>phk@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>In the overall area of disk and device I/O, a significant - milestone was reached with the implementation of proper - reference counting on dev_t. We are now able to properly - allocate and free dev_t. Cloning device drivers also had - the job made easier for them with the addition of the unit - number management routines.</p> - <p>It is not quite decided which will be the next step in - the quest for a truly SMPng I/O subsystem, but a leading - candidate is to implement the device-access vnode bypass - to get more concurrency in the system: Instead of taking - the tour through the vnodes for each i/o operation on a - device we will go directly from the file descriptor layer to - DEVFS/SPECFS. In addition to Giant-less disk I/O, - this should enable us to pull the entire tty subsystem - and the PTY driver out from under Giant and we expect that - to improve the "snappiness" of the system measurably.</p> - </body> - </project> - <project> - <title>The FreeBSD Dutch Documentation Project.</title> - <contact> - <person> - <name> - <given>Remko</given> - <common>Lodder</common> - </name> - <email>remko@elvandar.org</email> - </person> - </contact> - <body> - <p>The Dutch Documentation Project is a ongoing project in - translating the handbook and other documentation to the dutch - language. Currently there is 1 active person (me) translating the - documentation. I am currently working on the handbook/basics - section. But i can use some more hands, please drop me an email if - you wish to help out so that the dutch translation will speed up - and be ready in some time. Contact remko@elvandar.org for - information.</p> - </body> - </project> - <project> - <title>Weekly cvs-src summaries</title> - - <contact> - <person> - <name> - <given>Mark</given> - <common>Johnston</common> - </name> - <email>mark@xl0.org</email> - </person> - </contact> - <links> - <url href="http://excel.xl0.org/FreeBSD/" /> - <url href="http://mocart.pinco.pl/FreeBSD/">Polish translations</url> - </links> - - <body> - <p>I have been producing weekly summaries of commits and the - surrounding discussions as reported on the cvs-src mailing list. - These summaries are posted to -current on Sunday evenings and - archived on the Web. The reception has been overwhelmingly good. - As of the end of February, Polish translations are being produced - by Lukasz Dudek and Szymon Roczniak; they are also - planning to translate the older summaries.</p> - </body> - </project> - <project> - <title>libarchive/bsdtar</title> - <contact> - <person> - <name> - <given>Tim</given> - <common>Kientzle</common> - </name> - <email>kientzle@FreeBSD.org</email> - </person> - </contact> - <links> - <url href="http://people.FreeBSD.org/~kientzle/"/> - </links> - <body> - <p>libarchive, with complete documentation, has been committed to - -CURRENT. bsdtar should follow soon. For a few months, gtar - and bsdtar will both be available in the base system. Once - bsdtar is in the tree, I hope to resume work on libpkg and my - pkg_add rewrite.</p> - - <p>Note that bsdtar is not an exact replacement for gtar: it does - some things better (reads/writes standard formats, archive ACLs - and file flags, detects format and compression automatically), - some things worse (does not handle multi-volume archives or - sparse files) and a few things just different (writes POSIX-format - archives by default, not GNU-format). The command lines are - sufficiently similar that most users should have no problems - with the transition. However, people who rely on peculiar - options or capabilities of gtar may have to look to ports.</p> - </body> - </project> - <project> - <title>Network interface naming changes</title> - - <contact> - <person> - <name> - <given>Brooks</given> - - <common>Davis</common> - </name> - - <email>brooks@FreeBSD.org</email> - </person> - </contact> - - <links> - </links> - - <body> - <p>The first actual feature related to the if_xname conversion was - committed in early February. Network interfaces can now be - renamed with "ifconfig <if> name <newname>".</p> - - <p>Work is slowly progressing on a new network interface cloning API - to enable interesting cloners like auto-configurating vlans. - This work is taking place in the perforce repository under: - //depot/user/brooks/xname/...</p> - </body> - </project> - <project> - <title>PowerPC Port</title> - - <contact> - <person> - <name> - <given>Peter</given> - <common>Grehan</common> - </name> - <email>grehan@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>After a slow time at the end of last year due to a disk crash, - the project is moving along rapidly. The loader is fully - functional with Forth support. Syscons has been integrated. - New Powerbook models are supported. Work is starting on a - G5 port.</p> - - <p>There's still lots to do, so as usual volunteers are most - welcome.</p> - </body> - </project> - <project> - <title>The FreeBSD Simplified Chinese Project</title> - <contact> - <person> - <name> - <given>Dong</given> - <common>LI</common> - </name> - <email>ld@FreeBSD.org.cn</email> - </person> - <person> - <name> - <given>Xin</given> - <common>LI</common> - </name> - <email>delphij@frontfree.net</email> - </person> - </contact> - <links> - <url href="http://www.FreeBSD.org.cn">The FreeBSD Simplified - Chinese Project (In Simplified Chinese)</url> - <url href="http://www.FreeBSD.org.cn/snap/zh_CN/">Translated - Website Snapshot</url> - <url href="http://www.FreeBSD.org.cn/snap/doc/zh_CN.GB2312/books/handbook/">Translated Handbook Snapshot</url> - </links> - <body> - <p>The project is a joint effort of volunteers, which focus in - the internationalization and localization of the FreeBSD - Operating System and applications running on FreeBSD. All of the - work resulted in this project will be contributed back to the - FreeBSD project.</p> - <p>Thanks to many volunteers' help, by this time of writing, we - have finished more than 60% of the translation of the FreeBSD - Handbook. We plan to submit a preliminary translation of the - FreeBSD website as well as the FreeBSD Handbook when most part of - them were finished, which is expected to happen in a couple of - months. The snapshot of the documentation translation effort - could be accessed through the URL listed above.</p> - <p>The project also supported individual efforts on porting - applications (especially software that supports Simplified - and/or Traditional Chinese) to FreeBSD. We are also doing some - research on making FreeBSD kernel and base system more - i18n-aware.</p> - </body> - </project> - <project> - <title>Verify source reachability option for ipfw2</title> - <contact> - <person> - <name> - <given>Andre</given> - <common>Oppermann</common> - </name> - <email>andre@FreeBSD.org</email> - </person> - </contact> - <links> - <url href="http://www.nrg4u.com/freebsd/ipfw_versrcreach.diff"/> - </links> - <body> - <p>The verify source reachability option for ipfw2 checks if the - source IP address of a packet entering the machine is reachable - at all. Thus if we can't send a packet back because we don't - have a route back we don't have to forward it because two way - communication isn't possible anyway. It is more than likely - that such a packet is spoofed. This option is almost the same as - what is known on Cisco IOS as "ip verify unicast source - reachable-via [any|ifn]". Using this option only makes sense - when you don't have a default route which naturally always - matches. So this is useful for machines acting as routers with - a default-free view of the entire Internet as common when running - a BGP daemon (Zebra/Quagga or OpenBSD bgpd).</p> - <p>One useful way of enabling it globally on a router looks like - this: ipfw add xxxx deny ip from any to any not versrcreach or for - an individual interface only: ipfw add xxxx deny ip from any to - any not versrcreach recv fxp0</p> - </body> - </project> - - <project> - <title>Move ARP out of routing table</title> - <contact> - <person> - <name> - <given>Andre</given> - <common>Oppermann</common> - </name> - <email>andre@FreeBSD.org</email> - </person> - </contact> - <body> - <p>The ARP IP address to MAC address mapping does not belong into - the routing table (FIB) as it is currently done. This will move - it to its own hash based structure which will be instantiated - per each 802.1 broadcast domain. With this change it is possible - to have more than one interface in the same IP subnet and layer 2 - broadcast domain. The ARP handling and the routing table will be - quite a bit simplified afterwards. As an additional benefit full - MAC address based accosting will be provided. Work on this - project is already in progress.</p> - </body> - </project> - <project> - <title>Automatic sizing of TCP send buffers</title> - <contact> - <person> - <name> - <given>Andre</given> - <common>Oppermann</common> - </name> - <email>andre@FreeBSD.org</email> - </person> - </contact> - <body> - <p>The current TCP send and receive buffers are static and set to a - conservative value to preserve kernel memory. This is sub-optimal - for connections with a high bandwidth*delay product because the - size of the TCP send buffer determines how big the send window - can get. For high bandwidth trans-continental links this seriously - limits the maximum transfer speed per TCP connection. For example - a 170ms RTT and a 32kB send buffer limit the speed to approximately - 1.5Mbit per second even thought you might have a 10Mbit pipe.</p> - <p>This project makes the TCP send buffer to automatically adapt to - the optimal buffer size for maximal link usage. In the case - above this would be a buffer of approximately 220kB. The main - challenge is to have a stable and reliable measurement of the link - parameters and manage the kernel memory properly and in a fair way. - We don't want to have a few connections to monopolize all available - socket buffer space and many edge cases have to be considered. The - first implementation will be tuned conservatively but even that - will provide significantly better performance than the static - buffers currently. Work on this project is already in - progress.</p> - </body> - </project> - - <project> - <title>Testbed for testing and qualification of TCP performance</title> - <contact> - <person> - <name> - <given>Andre</given> - <common>Oppermann</common> - </name> - <email>andre@FreeBSD.org</email> - </person> - </contact> - <body> - <p>The TCP performance test and qualification testbed is an automated - environment that simulates various common and uncommon end-to-end - network and link characteristics such as delay, bandwidth - limitations, congestion, packet drops, packet corruption and out - of order arrival. The testbed automatically steps through all - link types and tests various TCP optimizations and parameter - adjustments. In the end all data is graphically arranged and - compared against standard behaviour and each other to judge the - positive or negative effects of the modifications. Work on this - project has just started and is based on FreeBSDs dummynet.</p> - </body> - </project> - <project> - <title>FreeBSD ports monitoring system</title> - - <contact> - <person> - <name> - <given>Mark</given> - <common>Linimon</common> - </name> - <email>linimon_at_lonesome_dot_com</email> - </person> - </contact> - - <links> - <url href="http://portsmon.firepipe.net/index.html"> - FreeBSD ports monitoring system</url> - </links> - - <body> - <p>Thanks to the loan of a box by Will Andrews, the system has - been moved into production. The previous installation - at lonesome.com now refers you to the new system. As part of - the installation, a preliminary - <a href="http://portsmon.firepipe.net/faq.html">FAQ</a> was - added.</p> - <p>The database is updated once per hour.</p> - <p>New reports available include ones about ports marked DEPRECATED, - since that function has now been incorporated into bsd.port.mk. - (The author hopes that this will allow the port deprecation process - to be much more visible to the general FreeBSD user community.) In - addition, a report for ports marked FORBIDDEN was added (the code - was essentially the same).</p> - <p>The next topic of interest is to try to identify ports which are - slave ports because the status of these ports is not currently - being updated automatically. This problem also affects - FreshPorts. PR ports/63683 is an attempt to address this problem. - Also, preliminary work has been done on creating some graphs and - charts for various statistics, and in creating a tool to browse - port dependencies for the entire ports tree.</p> - <p>Some general observations about the trends in ports PRs can be - made: - <ul> - <li>In the past 6 months, the amount of time to get ports PRs - committed has dropped dramatically. (This is especially - true of PRs for new ports.)</li> - <li>The queue of PRs for existing ports that are unmaintained - has similarly been trimmed. Both of these two items are due - in large part to a few very active committers (how do they - ever get their "real" work done?) Thanks, guys, you know who - you are.</li> - <li>There is still a fairly high number of PRs (~400/~750) which - apply to existing ports, and have been assigned to a FreeBSD - committer. This represents around 370 individual ports. We - seem to have a much harder time getting these numbers to go - down; basically, we just hold our own most weeks. This is - somewhat disappointing.</li> - <li>The number of ports marked BROKEN has jumped dramatically, - currently standing at over 250 (for i386-current). This - represents less a sudden problem as it does Kris' effort to - bring existing brokenness to people's attention -- thus, a - much larger percentage of ports with build errors are now - labeled as BROKEN.</li> - <li>Approximately two-thirds of the port build errors are still - due to compilation problems, primarily from the gcc3.3 import. - Another 10% fail to install correctly. The reasons for the - others are more varied.</li> - </ul> - </p> - </body> - </project> - <project> - <title>FreeSBIE</title> - <contact> - <person> - <name> - <given>FreeSBIE</given> - <common>Staff</common> - </name> - <email>staff@FreeSBIE.org</email> - </person> - </contact> - <links> - <url href="http://www.freesbie.org">FreeSBIE Home</url> - <url href="mailto:freesbie@gufi.org">FreeSBIE Mailing - List</url> - <url href="http://www.freesbie.org/?section=mirror-en">FreeSBIE - Mirror List</url> - </links> - <body> - <p>The FreeSBIE Project aims to develop a set of scripts that allow - anyone to create their own FreeBSD Bootable Cdrom, with their own - set of installed packages. The Project releases an ISO builded - with FreeSBIE scripts, to show what they can do. On Sunday 29 - February 2004, FreeSBIE 1.0 was released and it had a great - success, as there were post on Slashdot.org, OSnews, DaemonNews - and BSDForums. Thanks to the huge amount of feedback they got, - FreeSBIE Developers are now developing new features such as - support for archs different from i386. Website redesign is on the - way too.</p> - </body> - </project> - <project> - <title>kgi4BSD</title> - <contact> - <person> - <name> - <given>Nicholas</given> - <common>Souchu</common> - </name> - <email>nsouch@FreeBSD.org</email> - </person> - </contact> - <links> - <url href="http://www.FreeBSD.org/~nsouch/kgi4BSD"> Project URL</url> - </links> - - <body> - <p>Move to Perforce is done. I spent some time on building a - common compilation tree with Linux: until now drivers were - build in a FreeBSD makefile tree, not compatible with Linux.</p> - - <p>The next priorities are ANSI support and keymaps in the - KGC Kernel Graphic Console system.</p> - </body> - </project> - - <project> - <title>FreeBSD/ia64</title> - - <contact> - <person> - <name> - <given>Marcel</given> - <common>Moolenaar</common> - </name> - <email>marcel@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://www.FreeBSD.org/platforms/ia64/index.html"> - Home page.</url> - </links> - - <body> - <p>Work on the PMAP overhaul has been put into gear. A lot of issues - will be addressed, including support for sparse physical memory - and of course SMP. Performance will be addressed to the extend - possible, but functionality has priority. The redesign will lay - the foundation for NUMA support where possible. An example of this - is limiting TLB shootdowns to processors that actually have or had - TLBs belonging to the PMAP loaded. Of course, without NUMA - hardware the implementation of NUMA support is quite limited.</p> - </body> - </project> - <project> - <title>FreeBSD Package Grid</title> - - <contact> - <person> - <name> - <given>Kris</given> - <common>Kennaway</common> - </name> - <email>kris@FreeBSD.org</email> - </person> - </contact> - - <body> - - <p>Distributed package builds are currently done using a set of - home-grown shell scripts for managing, scheduling and - dispatching of package builds on the client machines. This has - been sufficient for our needs in the past, but has a number of - significant shortcomings that limit future growth. I am - rewriting the package build scripts to work on top of Sun - GridEngine (ports/sysutils/sge), as a client application of a - "FreeBSD package grid". Some of the design goals for the new - system are:</p> - - <ul> - <li>Better robustness against machine failure, and more efficient - scheduling of build jobs</li> - <li>Support for remote build machines, to make better use of machine - resources and clusters that are not on the same LAN as the - build master</li> - <li>Ability for other committers to submit port build jobs to the - system, for testing of changes, new ports, etc.</li> - </ul> - - </body> - </project> - <project> - <title>vinum + GEOM</title> - <contact> - <person> - <name> - <given>Lukas</given> - <common>Ertl</common> - </name> - <email>le@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://mailbox.univie.ac.at/~le/geom_vinum.tar.gz" /> - </links> - - <body> - <p>The "geomification" of vinum has made some progress. I now have - all basic setups working (concatenated plexes, striped plexes, - RAID5 plexes, and RAID1), but I still have to implement correct - error handling and status change handling.</p> - <p>Still missing is a userland tool, so currently you still have to - use "old-style" vinum to configure your setup.</p> - </body> - </project> - <project> - <title>NanoBSD</title> - - <contact> - <person> - <name> - <given>Poul-Henning</given> - <common>Kamp</common> - </name> - <email>phk@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>NanoBSD, src/tools/tools/nanobsd, is a tool for stuffing FreeBSD - onto small disk media (like CompactFlash) for embedded - applications. The disk image is built with three partitions, two - for software images and one for configuration files. Having two - software partitions means that new software can be uploaded to the - non-active partition while running off the active partition.</p> - <p> The first really public version has been committed and many - suggestions and offers of patches have started pouring in.</p> - </body> - </project> - <project> - <title>Porting OpenBSD's pf</title> - <contact> - <person> - <name> - <given>Max</given> - <common>Laier</common> - </name> - <email>max@love2party.net</email> - </person> - <person> - <name> - <given>Pyun</given> - <common>YongHyeon</common> - </name> - <email>yongari@kt-is.co.kr</email> - </person> - </contact> - - <links> - <url href="http://pf4freebsd.love2party.net/" /> - <url href="http://www.benzedrine.cx/pf.html">PF homepage</url> - <url href="http://openbsd.org/faq/pf/index.html">PF FAQ</url> - <url href="http://www.rofug.ro/projects/freebsd-altq/">ALTQ</url> - </links> - - <body> - <p>The sources were imported from OpenBSD 3.4R and patched with - diffs obtained from the port. Since March the 8th it is linked - to the build and install. There is some more work to be done in - order make pf a home inside the tree, but the biggest hunk of - work was lifted during the past two month.</p> - <p>OpenBSD 3.5 is scheduled for early May, so we might see an update - before 5.3R. Work towards integration of the - often requested - - ALTQ framework is in progress also, though it is not yet clear - how well it goes along with the ongoing work towards a giant free - net stack.</p> - </body> - </project> - <project> - <title>FreeBSD/arm Status Report</title> - <contact> - <person> - <name> - <given>Olivier</given> - <common>Houchard</common> - </name> - <email>cognet@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>Development goes reasonably fast, right now it boots single user. - It is still very simics-centric, and it deserves a huge cleanup - and a few bug fixes, but there's already a decent amount of code - to work with, mostly taken from NetBSD. I now plan to work on real - hardware support (as soon as I can get some), to get the missing - userland bits (mainly rtld and the pthread libs) so that I can - build a full world.</p> - </body> - </project> - <project> - <title>SGI XFS port for FreeBSD</title> - <contact> - <person> - <name> - <given>Alexander</given> - <common>Kabaev</common> - </name> - <email>kan@FreeBSD.org</email> - </person> - <person> - <name> - <given>Russell</given> - <common>Cattelan</common> - </name> - <email>cattelan@thebarn.com</email> - </person> - </contact> - - <body> - <p>Not much has changed since last report was submitted. The - read-only access XFS volumes is quite stable now. The work is - underway to rewrite xfs_buf layer to minimize local changes - intrusiveness. Initial attempt to make XFS code to compile and - run on amd64 is in progress too.</p> - <p>We really need a care-taker for our userland tools.</p> - </body> - </project> - <project> - <title>Compile FreeBSD with Intels C compiler (icc)</title> - - <contact> - <person> - <name> - <given>Alexander</given> - <common>Leidinger</common> - </name> - <email>netchild@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://www.Leidinger.net/FreeBSD/">Some patches.</url> - </links> - - <body> - <p>If nothing bad happened, the icc patches got committed around - the date of the deadline for submissions of this report. Please - search the archives of -current and/or cvs-all for more - information.</p> - - <p>The next steps in this project are to - <ul> - <li>fix the kernel to also run without problems when compiled - with icc v8</li> - <li>fix the kernel if some problems surface after more people - give it a try</li> - <li>get some ports to compile with icc</li> - </ul> - </p> - </body> - </project> - <project> - <title> - Bluetooth stack for FreeBSD (Netgraph implementation) - </title> - - <contact> - <person> - <name> - <given>Maksim</given> - <common>Yevmenkin</common> - </name> - <email>m_evmenkin@yahoo.com</email> - </person> - </contact> - - <body> - <p>Not much to report. Bluetooth Service Discovery Procotol daemon - sdpd was integrated with existing Bluetooth utilities. From now - on users should not use GNU sdpd (Linux BlueZ port).</p> - <p>Bluetooth HID profile implementation is almost complete. Thanks - to Matt Peterson < matt at peterson dot org > for giving me - Bluetooth keyboard and mouse for development.</p> - </body> - </project> - <project> - <title>FreeBSD GNOME Project Report</title> - - <contact> - <person> - <name> - <given>FreeBSD</given> - <common>GNOME Team</common> - </name> - <email>gnome@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://www.FreeBSD.org/gnome/">FreeBSD GNOME Project - Site.</url> - </links> - - <body> - <p>It has been a year since our last status report, but we - haven't slowed down. Since the last report, Alexander - Nedotsukov (bland) and Pav Lucistnik (pav) have joined the - FreeBSD GNOME team. GNOME 2.4 was released back in September - 2003, followed by 2.4.1 and 2.4.2. We are actively working on - getting GNOME 2.6.0 out the door at the end of March. GNOME 2.6 - Beta releases can be obtained via the project URL above.</p> - - <p>To help make GNOME 2.6.0 our best release to date, we have - created a script to automate the upgrade from GNOME 2.4. We - also have a new GNOME - <a href="http://www.marcuscom.com/tinderbox/">package build - server</a> - that builds and serves i386 packages for all supported FreeBSD - releases. We plan on having the GNOME 2.6.0 packages available - the moment 2.6.0 hits the ports tree.</p> - - <p>Included in the release of GNOME 2.6 is GTK+ 2.4, the next - installment in the GTK+ 2 series. Because GTK+ 2 has become - very stable over the past few years, the FreeBSD GNOME Team is - pushing for GTK+ 2 support to be included by default in all - applications that support it. This has already been done with - Mozilla, Firefox, and Thunderbird. A complete GNOME Desktop and - application environment can already be built using only GTK+ 2. - The ultimate goal is to phase GTK+ 1 out of the ports tree.</p> - </body> - </project> - <project> - <title>Network Stack Locking</title> - - <contact> - <person> - <name> - <given>Sam</given> - <common>Leffler</common> - </name> - <email>sam@FreeBSD.org</email> - </person> - - <person> - <name> - <given>Robert</given> - <common>Watson</common> - </name> - <email>rwatson@FreeBSD.org</email> - </person> - </contact> - - <links> - </links> - - <body> - <p>This project is aimed at converting the FreeBSD network stack from - running under the single Giant kernel lock to permitting it to - run in a fully parallel manner on multiple CPUs (i.e., a fully - threaded network stack). This will improve performance/latency - through reentrancy and preemption on single-processor machines, - and also on multi-processor machines by permitting real - parallelism in the processing of network traffic. As of FreeBSD - 5.2, it was possible to run low level network functions, as well - as the IP filtering and forwarding plane, without the Giant lock, - as well as "process to completion" in the interrupt handler.</p> - - <p>Work continues to improve the maturity and completeness of - the locking (and performance) of the network stack for 5.3. The - network stack locking development branch has been updated to the - latest CVS HEAD, tracking a variety of FreeBSD changes, including - tracking and driving changes in the interface and device cloning - APIs, push-down and fixes to locking in the Berkeley Packet - Filter, consistency improvements in allocation flags for network - objects, diagnosis of excessive acquisition of Giant in various - system callouts and timeouts, removal of Giant from several - system callouts, "const"-ification of a number of global - variables in the network stack (IPv4, IPv6, elsewhere) as part of - ananalysis of locking requirements, fine-grain locking of a - number of pseudo-interfaces (disc, loopback, faith, stf, gif, tap, - tun), IP encapsulation and tunneling, initial review and locking - of parts of PPP and SLIP, experimentation with PCB assertions on - IPv6, additional socket locking assertions, graphing of the FreeBSD - sockets layer to support locking analysis, merging of theMT_TAG to - m_tag conversion to improve the ability to queue packets, moving - of the debug.mpsafenet tunable to controlling Giant over the - forwarding plane to Giant over the entire stack("dual-mode" to - support non-MPSAFE protocols), adaption of existing network lock - assertions to also assert Giant when running non-MPSAFE, analysis - of high cost of select() locking, improved locking and - synchronization annotations, TCP callouts run MPSAFE, logtimeout() - runs MPSAFE, uma_timeout() runs MPSAFE, callout sampling - instrumentation, loadav() runs MPSAFE, AppleTalk locking begun: - AARP locked down and DDP analysis, rawcb list locked, locking - analysis of mrouter and IP ID code, IGMP locked, IPv6 analysis - begun, IPX/SPX analysis begun, PPP timeouts converted to callouts, - Netgraph analysis begun. Many of these changes have not yet been - merged to the main FreeBSDtree, but this is a work in progress.</p> - - <p>In related work on Pipe IPC (not quite network stack locking), - substantial time was invested in diagnosing an increase in the - cost of pipe allocation since FreeBSD 4.x, as well as coalescing - the several allocations needed to create a pipe, as well as moving - to slab allocation so as to amortize the cost of pipe - initialization. Future work here will include caching the VM - structures supporting pipe buffers.</p> - - <p>Recent contributors include Robert Watson, Sam Leffler, MaxLaier, - Maurycy Pawlowski-Wieronski, Brooks Davis, and many others who are - omitted here only by accident.</p> - </body> - </project> -</report> |