diff options
Diffstat (limited to 'en/news/status/report-2002-11-2002-12.xml')
| -rw-r--r-- | en/news/status/report-2002-11-2002-12.xml | 877 |
1 files changed, 0 insertions, 877 deletions
diff --git a/en/news/status/report-2002-11-2002-12.xml b/en/news/status/report-2002-11-2002-12.xml deleted file mode 100644 index 7cf255898c..0000000000 --- a/en/news/status/report-2002-11-2002-12.xml +++ /dev/null @@ -1,877 +0,0 @@ -<!-- $FreeBSD: www/en/news/status/report-nov-2002-dec-2002.xml,v 1.4 2004/04/05 14:46:17 phantom Exp $ --> - -<report> - <date> - <month>November-December</month> - <year>2002</year> - </date> - - <section> - <title>Introduction:</title> - - <p>At long last, FreeBSD 5.0 is here. Along with putting the final - polish on the tree, FreeBSD developers somehow found the time to - work on other things too. IA64 took some major steps towards - working on the Itanium2 platform, an effort was started to - convert all drivers to use busdma and ban vtophys(), hardware - crypto support and DEVD hit the tree, NewReno was fixed and - effort began on locking down the network layer of the kernel. - Also high performance, modular scheduler started taking shape - and will be a welcome addition to the kernel soon.</p> - - <p>Looking forward, the focus will be on stabilizing and - improving the performance of 5.0. The RELENG_5 (aka 5-STABLE) - branch will be created once we've reached our goals in this - area, so hopefully we will get there quickly. Meanwhile, - preparations for the next release from the 4.x series, 4.8, - will begin soon. Of course, the best way to get 5.x to - stabilize os to install and run it!</p> - - <p>Thanks,</p> - - <p>Scott Long, Robert Watson</p> - </section> - -<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> - - <links> - <url href="http://www.geocities.com/m_evmenkin/">Latest snapshot</url> - - <url href="http://bluez.sf.net">Linux BlueZ stack</url> - - <url href="http://sourceforge.net/projects/openobex">OpenOBEX</url> - </links> - - <body> - <p>I'm very pleased to announce that all kernel modules and few userland - tools made it to the FreeBSD source tree. Many thanks to Julian - Elischer.</p> - - <p>Unfortunately no big changes since the last report. Some minor problems - have been discovered and patches are available on request. I will prepare - all the patches and submit them to Julian for review.</p> - - <p> OBEX server and client (based on OpenOBEX library) is almost complete. - I'm currently doing interoperability testing. If anyone has hardware and - time please contact me. The HCI security daemon has been implemented and - tested with Sony Ericsson T68i cell phone and Windows stack. It is now - possible to setup secure Bluetooth connections.</p> - - <p>A few people have complained about RFCOMM daemon. These individuals want - to use GPRS and Bluetooth enabled cell phone to access Internet. If you - have this problem please contact me for possible workaround. My next goal - is to get robust RFCOMM implementation to address all these issues.</p> - </body> -</project> - -<project> - <title>TrustedBSD Project: Access Control Lists</title> - - <contact> - <person> - <name> - <given>Robert</given> - - <common>Watson</common> - </name> - - <email>rwatson@FreeBSD.org</email> - </person> - <person> - <name> - <common>TrustedBSD Discussion List</common> - </name> - - <email>trustedbsd-discuss@TrustedBSD.org</email> - </person> - </contact> - - <links> - <url href="http://www.TrustedBSD.org/">TrustedBSD Project</url> - </links> - - <body> - <p>Largely bug-fixing and userland application tweaks; new - interfaces were added to manipulate ACLs on extended attributes; - bugs were fixed in ls relating to ACL flagging. Patches to - teach cp, mv, gzip, bzip, and other apps about ACL preservation - are in testing and review. tunefs flags were added to ease - configuration of ACLs, especially on UFS2 file systems.</p> - <p>Possible changes to make use of Linux/Solaris umask semantics - are under consideration: right now we implement verbatim - POSIX.1e/IRIX merging of the umask, ACL mask, and requested - creation mode during file, device, fifo, and directory creation. - Solaris and the most recent Linux patches ignore the umask in - the context of a default ACL; this requires some rearrangement - of umask handling in our VFS, although the results would be - quite useful. We're exploring how to do this in a low impact - way.</p> - </body> -</project> - -<project> - <title>TrustedBSD Project: MAC Framework</title> - - <contact> - <person> - <name> - <given>Robert</given> - - <common>Watson</common> - </name> - - <email>rwatson@FreeBSD.org</email> - </person> - <person> - <name> - <common>TrustedBSD Discussion List</common> - </name> - - <email>trustedbsd-discuss@TrustedBSD.org</email> - </person> - </contact> - - <links> - <url href="http://www.TrustedBSD.org/">TrustedBSD Project</url> - </links> - - <body> - <p>Framework changes:</p> - <p>Instrument KLD system calls (module and kld load, unload, stat) - Instrument NFSd system call. Instrument swapoff(2). - Instrument per-architecture privileged parts of sysarch(). - Make use of condition variables to allow callers to wait for the - framework to "unbusy" when loading/unloading policies, rather than - returning EBUSY. Store mount pointer in devfs_mount structure for - use by policies. Improve handling of labels in loopback interface - "re-align" packet copy case. Provide full paths on devfs object - creations to help policies label them properly (not merged). - Experimentation with moving MAC labels into m_tags (not merged). - NFS server now uses real ucreds, not hacked up ucreds, - meaning we can start laying the groundwork for enforcement on - NFS operations. (not merged)</p> - - <p>Policy changes</p> - <p>LOMAC: mac_lomac replaces lomac (LOMAC now uses the MAC Framework), - SEBSD: Improved support for devfs labeling based on SELinux genfs. - Handling of hard link checks. Support export of process transition - information for login and others using sysctl. Login now prompts - for roles. Allow policy reload. TTY labeling. Locking adaptation - from Linux. Many, many policy adaptations and fixes. We can - now boot in enforcing mode! mac_bsdextended: fix a bug in which - VAPPEND wasn't mapped to VWRITE, so opens with the O_APPEND bug - failed improperly.</p> - - <p>Userland changes</p> - <p>setfmac(8) now supports a setfsmac(8) execution mode, which accepts - initial labeling specification files. Supports an SELinux compatibility - mode so it can accept SELinux label specfiles using the SEBSD module. - sendmail(8) now sets user labels as part of the context switch for mail - delivery.</p> - - <p>Documentation changes</p> - <p>Man page updates for MAC command line tools, modules, admin hints, etc. - Updates to the FreeBSD Developer's Handbook chapter on MAC policies - and entry points. MAC section in FreeBSD Handbook.</p> - </body> -</project> - -<project> - <title>busdma driver conversion project</title> - - <contact> - <person> - <name> - <given>Maxime</given> - - <common>Henrion</common> - </name> - - <email>mux@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://www.FreeBSD.org/projects/busdma/" /> - </links> - - <body> - <p>This project has been coming along pretty well. The amd(4) and - xl(4) drivers have now been converted to use the busdma API, - sparc64 got the bus_dmamap_load_mbuf() and bus_dmamap_load_uio() - functions, and the gem(4) and hme(4) drivers have been updated - to use bus_dmamap_load_mbuf() instead of bus_dmamap_load().</p> - - <p>A lot more still needs to be done, as shown on the project's - page. A fair number of conversions are on their way though, - and we can expect a fair number of drivers to be converted - soon, thanks to all the developers who are working on this - project.</p> - </body> -</project> - -<project> - <title>FreeBSD C99 & POSIX Conformance Project</title> - - <contact> - <person> - <name> - <given>Mike</given> - <common>Barcroft</common> - </name> - - <email>mike@FreeBSD.org</email> - </person> - <person> - <name> - <common>FreeBSD-Standards Mailing List</common> - </name> - - <email>standards@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://www.FreeBSD.org/projects/c99/" /> - <url href="http://people.FreeBSD.org/~schweikh/posix-utilities.html" /> - </links> - - <body> - <p>The POSIX Utility Conformance in FreeBSD list (link above) has - been updated to reflect current reality. Not much work remains - to complete base utility conformance.</p> - - <p>On the API front, grantpt(), posix_openpt(), unlockpt(), - wordexp(), and wordfree() were implemented. The header - <wordexp.h> was added.</p> - - <p>There are currently about 40 unassigned tasks on our project's - status board ranging from documentation, utilities, to kernel - hacking. We would encourage any developers looking for something - to work on to check out the status board and see if anything - interests them.</p> - </body> -</project> - -<project> - <title>Hardware Crypto Support Status</title> - - <contact> - <person> - <name> - <given>Sam</given> - <common>Leffler</common> - </name> - - <email>sam@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>The goal of this project is to import the OpenBSD kernel-level crypto - subsystem. This facility provides kernel- and user-level access to - hardware crypto devices for the calculation of cryptographic hashes, - ciphers, and public key operations. The main clients of this facility - are the kernel RNG (/dev/random), network protocols (e.g. IPsec), and - OpenSSL (through the /dev/crypto device).</p> - - <p>This work will be part of the 5.0 release and has been committed to - the -stable source tree for inclusion in the 4.8 release.</p> - - <p>Recent work has focused on improving performance. System statistics are - now maintained and an optional profiling facility was added for - analyzing performance. Using this facility the overhead for using the - crypto API has been significantly reduced.</p> - - <p>The ubsec (Broadcom) driver was changed to significantly improve - performance under load. In addition several memory leaks were fixed in - the driver and the public key support was enabled for use.</p> - - <p>Upcoming work will focus on load-balancing requests across multiple - crypto devices and integrating OpenSSL 0.9.7 which will automatically - enable application use of crypto hardware.</p> - </body> -</project> - -<project> - <title>DEVD</title> - - <contact> - <person> - <name> - <given>Warner</given> - <common>Losh</common> - </name> - - <email>imp@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>Devd has been integrated into FreeBSD 5.0-RELEASE. The - integrated code supports a range of configuration options. The - config files are fully parsed now and their actions are - performed.</p> - - <p>Future work in this area is likely to be limited to improving - the devctl interface. /dev/devctl likely will be a cloneable - device in future versions. Individual device control via devctl - is also planned.</p> - </body> -</project> - -<project> - <title>Donations Team Status Report</title> - - <contact> - <person> - <name> - <given>Michael</given> - <common>Lucas</common> - </name> - - <email>donations@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://www.FreeBSD.org/donations/">Donations main page</url> - <url href="http://www.FreeBSD.org/donations/wantlist.html">FreeBSD - developer wantlist</url> - <url href="http://www.FreeBSD.org/donations/donors.html"> - completed donations</url> - </links> - - <body> - <p>The Donations project expedited several dozen donations during - 2002, and was able to place most of what was offered. We still - are in dire need of SMP and Sparc systems. You can see - information on our needs and donations that have been handled by - the team on the donations web page.</p> - - <p>We are relying increasingly upon the developer wantlist to - place items offered to the Project, and using the commit - statistics to help place items. As such, active committers who - ask for what they want beforehand have a decent chance of - getting it. Less active committers, and committers who do not - ask for what they want, will be lower in our priorities but will - not be excluded.</p> - - <p>We are in the process of streamlining the tax deduction process - for donations, and hope to have news on that shortly. We are - also always working to accelerate and reduce our internal - processes, to get the most equipment in the hands of the most - people as quickly as possible.</p> - - <p>I especially want to thank David O'Brien and Tom Rhodes for - stepping up and making the team far more successful. Also, the - FreeBSD Foundation has been quite helpful in handling - tax-deductible contributions.</p> - </body> -</project> - - - -<project> - <title>Fast IPsec Status</title> - - <contact> - <person> - <name> - <given>Sam</given> - <common>Leffler</common> - </name> - - <email>sam@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>The main goal of this project is to modify the IPsec protocols to use - the kernel-level crypto subsystem imported from OpenBSD (see elsewhere). - A secondary goal is to do general performance tuning of the IPsec - protocols.</p> - - <p>This work will be part of the 5.0 release. Performance has been improved - due to work on the crypto subsystem.</p> - </body> -</project> - -<project> - <title>FFS volume label support</title> - - <contact> - <person> - <name> - <given>Gordon</given> - <common>Tetlow</common> - </name> - - <email>gordon@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://people.FreeBSD.org/~gordon/patches/volume.diff">Current patch set.</url> - </links> - - <body> - <p>The goal of the project is to use a small amount of space in the FFS - superblock to store a volume label of the user's choice. A GEOM module - will then expose the volume labels into a namespace in devfs. The idea - is to make it easier to manage filesystems across disk swaps and - movement from system to system.</p> - - <p>At this point, everything pretty much works. I've submitted parts of - the patch to respective subsystem maintainers for review. There are some - issues with namespace collision that I haven't addressed yet, but the - basic functionality is there</p> - </body> -</project> - -<project> - <title>French FreeBSD Documentation Project</title> - <contact> - <person> - <name> - <given>Sebastien </given> - <common>Gioria</common> - </name> - - <email>gioria@FreeBSD.org</email> - </person> - <person> - <name> - <given>Marc </given> - <common>Fonvieille</common> - </name> - <email>blackend@FreeBSD.org</email> - </person> - <person> - <name> - <given>Stéphane</given> - <common>Legrand</common> - </name> - <email>stephane@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://www.freebsd-fr.org">The French FreeBSD Documentation Project.</url> - <url href="http://www.freebsd-fr.org/index-trad.html">The FreeBSD Web Server translated in French.</url> - <url href="http://people.FreeBSD.org/~blackend/doc/fr_FR.ISO8859-1/books/handbook/"> Translation of the hanbook.</url> - <url href="http://www.FreeBSD-fr.info">French Daemon News like web site.</url> - </links> - - <body> - <p>Most of the articles are translated too. Marc is still translating the - handbook, 60% is currently translated. Stéphane has began the - integration of our French localization web site in the US CVS Tree. - Sébastien is still maintaining the Release Notes.</p> - - <p>We launched a new site, www.FreeBSD-fr.info, consisting in a French - Daemon News like site. Netasq have donated our new server; we will - install it in a new hosting provider in the few next weeks. One of the - big job now is the translation of the FAQ, and the big - project will be the manual pages.</p> - </body> -</project> - -<project> - <title>FreeBSD GNOME Project</title> - - <contact> - <person> - <name> - <given>Joe</given> - <common>Marcus</common> - </name> - - <email>marcus@FreeBSD.org</email> - </person> - <person> - <name> - <given>Maxim</given> - <common>Sobolev</common> - </name> - - <email>sobomax@FreeBSD.org</email> - </person> - <person> - <name> - <given>Adam</given> - <common>Weinberger</common> - </name> - - <email>adamw@FreeBSD.org</email> - </person> - - </contact> - - <links> - <url href="http://www.FreeBSD.org/gnome/">FreeBSD GNOME Project - Homepage.</url> - </links> - - <body> - <p>Since the ports tree has been frozen for most of this reporting period, - there have not been too many GNOME updates going into the official CVS - tree. However, development has not stopped. GNOME 2.2 is nearing - completion, and quite a few FreeBSD users have stepped up to test the - GNOME 2.1 port sources from the - <a href="http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi">MarcusCom - CVS repository</a>. If anyone else is interested, follow the - instructions on the aforementioned cvsweb URL, and checkout the "ports" - module.</p> - - <p>The upcoming FreeBSD 5.0-RELEASE will be the first release to have the - GNOME 2.0 desktop as the default GNOME desktop choice. During the - previously mentioned ports freeze, all the GNOME 2 ports were fixed up - so that they build and package on both i386 and Alpha platforms. Alas, - the one port that will not make the cut for Alpha is Mozilla. There are - still problems with the xpcom code, but work is ongoing to get a working - Alpha port.</p> - - <p>Finally, the FreeBSD Mono (an OpenSource C# runtime) port has also - received some new life. Mono has been updated to 0.17 (the latest - released version), and Juli Mallett has ported gtk-sharp (GTK+ bindings - for C#).</p> - </body> -</project> - -<project> - <title>FreeBSD/ia64 Status</title> - - <contact> - <person> - <name> - <given>Peter</given> - <common>Wemm</common> - </name> - - <email>peter@FreeBSD.org</email> - </person> - <person> - <name> - <given>Marcel</given> - <common>Moolenaar</common> - </name> - - <email>marcel@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://people.FreeBSD.org/~peter/ia64.diff" /> - <url href="http://www.FreeBSD.org/platforms/ia64/" /> - </links> - - <body> - <p>The ia64 port is up and running on the new Itanium2 based hp - machines thanks to a lot of hard work by Marcel Moolenaar. So - far we are running on the hp rx2600 as these were the machines - graciously donated by Hewlett-Packard and Intel. We had a - prototype Intel Tiger4 system for a while, but we had to return - the machine and we do not know if it currently runs. Most of - the changes necessary to run these are sitting in the perforce - tree and are not in the -current or RELENG_5 cvs tree. As a - result, the cvs derived builds (-current and the 5.0-RC series - and presumably 5.0-RELEASE) are only usable on obsolete Itanium1 - systems.</p> - - <p>Lots of other stability and functionality fixes have been made - over the last few months, including initial libc_r support. The - OS appears to be stable enough for sustained workloads - it is - building packages now, for example. We still do not have gdb - support, even for reading core files.</p> - </body> -</project> - -<project> - <title>jpman project</title> - - <contact> - <person> - <name> - <given>Kazuo</given> - <common>Horikawa</common> - </name> - - <email>horikawa@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://www.jp.FreeBSD.org/man-jp/">jpman project</url> - </links> - - <body> - <p>We have been updating our Japanese translated manual pages to - RELENG_5 based. All existing entries have been updated, but 15 - exceptions are not, most of which require massive update. We - will also need to add translations which did not exist on RELENG_4.</p> - </body> -</project> - -<project> - <title>KGI/FreeBSD Status Report</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/ggiport.html" /> - <url href="http://www.kgi-project.org" /> - </links> - - <body> - <p>KGI (Kernel Graphic Interface) is a kernel infrastructure providing user - applications with means to access hardware graphic resources (dma, - irqs, mmio). KGI is already available under Linux as a separate - standalone project. The KGI/FreeBSD project aims at integrating KGI - in the FreeBSD kernel.</p> - - <p>KGI/FreeBSD has been recently donated 2 PCI graphic cards (Matrox - Millenium II and a coming Mach64) and other have been proposed. - Please see the FreeBSD web pages for details. Thanks to donation@ for - organizing and promoting donations. Thanks to the donators for their - contribution to KGI/FreeBSD.</p> - - <p>KGI/FreeBSD progressed fine the last months. Most of the VM issues for - mapping HW resources in user space have been addressed and a first - attempt of coding was made. This prototyping raised some API - compatibility problems with the current Linux implementation and was - discussed heavily on the kgi devel lists. Ask if you're - interested in such issues, I'll be pleased to share them.</p> - - <p>Most of coding is now done. Let's start debugging!</p> - </body> -</project> - -<project> - <title>SMP locking for network stack</title> - - <contact> - <person> - <name> - <given>Jeffrey</given> - <common>Hsu</common> - </name> - - <email>hsu@FreeBSD.org</email> - </person> - </contact> - - <body> - <p> Work is ongoing to continue to lock up the network stack. - Recently, the focus has been on the IP stack. The plan there - involves a series of inter-related pieces to lock up the - ifaddr ref count, the inet list, the ifaddr uses, the ARP code, - the routing tree, and the routing entries. We are over 3/5 of - the way done down this path.</p> - - <p>In addition to TCP and UDP, the other networking protocols - such as raw IP, IPv6, AppleTalk, and XNS need to be locked up. - Around 1/4 these remaining protocols have been locked and - will be committed after the IP stack is locked.</p> - - <p>The protocol independent socket layer needs to be locked and - operating correctly with the protocol dependent locks. This - part is mostly done save for much needed testing and code cleanup.</p> - - <p>Finally, a pass will be need to be made to lock up the devices drivers - and various statistics counters.</p> - </body> -</project> - -<project> - <title>TCP congestion control</title> - - <contact> - <person> - <name> - <given>Jeffrey</given> - <common>Hsu</common> - </name> - - <email>hsu@FreeBSD.org</email> - </person> - </contact> - - <links> - </links> - - <body> - <p>This effort fixes some outstanding problems in our TCP - stack with regard to congestion control. The first - item is to fix our NewReno implementation. Following that, - the next urgent correction is to fix a problem involving window updates - and dupack counts. When that stabilizes, we will then change - the recovery code to make use of SACK information. - Eventually, this project will update the BSD stack to add Limited Transmit - and other new internet standards and standards-track improvements.</p> - </body> -</project> - -<project> - <title>FreeBSD Package Cluster work</title> - - <contact> - <person> - <name> - <given>Kris</given> - <common>Kennaway</common> - </name> - - <email>kris@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://bento.FreeBSD.org/" /> - </links> - - <body> - <p>The 3 FreeBSD package clusters (i386, alpha, sparc64) have been - unified to run from the same master machine, instead of using 3 - separate masters. This has freed up some machine resources to - use as additional client machine, as well as simplifying - administrative overheads. Build logs for all 3 architectures - can now be found on the http://bento.FreeBSD.org webpage. The - sparc64 package cluster now has 3 build machines (an u5 and two - u10s), and an ia64 cluster is about to be created.</p> - - <p>Package builds now keep track of how many sequential times a - port has failed to build (html summaries are available on the - bento website). This allows tracking of ports which have - suddenly become broken (e.g. due to a bad upgrade, or due to - changes in the FreeBSD source tree), and in the future will be - used to send out notifications to port maintainers when their - port fails to build 5 times in a row. This feature is currently - experimental, and further code changes will be needed to - stabilize it.</p> - </body> -</project> - -<project> - <title>Wireless Networking Status</title> - - <contact> - <person> - <name> - <given>Sam</given> - <common>Leffler</common> - </name> - - <email>sam@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>The goal of this project is to improve the wireless networking support in - the system. By the time of this report the 802.11 link layer code should - be committed. A version of the wi driver that uses this code should be - committed shortly. Conversion of other drivers is planned as are drivers - for new devices.</p> - - <p>Support for 802.1x/EAP is the next planned milestone (both as a - supplicant and authenticator).</p> - </body> -</project> - -<project> - <title>FreeBSD Release Engineering</title> - - <contact> - <person> - <name> - <given>Scott</given> - <common>Long</common> - </name> - - <email>re@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="http://www.FreeBSD.org/releng/index.html">Release Engineering - Homepage</url> - </links> - - <body> - <p>November and December were especially busy for the release engineering - team. Scott Long joined the team to help with secretary and - communications tasks while Brian Somers bowed out to focus on other - projects.</p> - - <p>FreeBSD 5.0-DP2 was released in November after much delay and - anticipation, and marked the final milestone needed for 5.0 to - become a reality. Shortly after that, we imposed a code freeze on - the HEAD branch of CVS and released 5.0-RC1. Creation of the - RELENG_5_0 branch came next, followed by the release of 5.0-RC2 from - this branch. At this point, enough critical problems still existed - that we scheduled an RC3 release for the new year, and pushed the - final 5.0-RELEASE date to mid-January. By the time this is published, - FreeBSD 5.0-RELEASE should be a reality.</p> - - <p>For the time being, there will not be a RELENG_5 (aka 5-STABLE) - branch. FreeBSD 4.x releases will continue, with 4.8 being - scheduled for March 2003. Release in the 4.x series will be - lead by Murray Stokely, and releases in the 5.x series will be - lead by Scott Long. Once HEAD has reached acceptable performance - and stability goals, the RELENG_5 branch will be created and HEAD - will move towards 6.0 development. We hope to reach this with - the 5.1 release this spring.</p> - </body> -</project> - -<project> - <title>SMP aware scheduler</title> - - <contact> - <person> - <name> - <given>Jeff</given> - <common>Roberson</common> - </name> - - <email>jeff@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>A new scheduler will be available as an optional component along side - the current scheduler in the 5.1 release. It has been designed to - work well with KSE and SMP. Some ideas have been borrowed from solaris - and linux along with many novel approaches. It has O(1) performance - with regard to the number of processes in the system. It also has - cpu affinity which should provide a speed boost for many applications.</p> - - <p>The scheduler has a few loose ends and lots of tuning before it is - production quality although it is quite stable. Please see the post - to arch and subsequent discussion for more details.</p> - </body> -</project> -</report> |