diff --git a/en/news/status/report-2009-10-2009-12.xml b/en/news/status/report-2009-10-2009-12.xml index 5b477f2105..98c5923d3b 100644 --- a/en/news/status/report-2009-10-2009-12.xml +++ b/en/news/status/report-2009-10-2009-12.xml @@ -1,1426 +1,1451 @@ - + October-December 2009
Introduction

This report covers &os; related projects between October and December 2009. Obviously, this is the last report in 2009, which has shown to be very important for the &os; Project. Beside other remarkable things, a new major version of &os;, 8.0-RELEASE, has been released, while the release process for 7.3-RELEASE is soon to begin.

Thanks to all the reporters for the excellent work! We hope you enjoy reading. Let us also use this opportunity to wish you all a happy and successful new year for 2010.

Please note that the next deadline for submissions covering the period between January and March 2010 is April 15th, 2010.

soc Google Summer of Code proj Projects team &os; Team Reports net Network Infrastructure kern Kernel docs Documentation arch Architectures ports Ports vendor Vendor / 3rd Party Software misc Miscellaneous bin Userland utilities DAHDI (Zaptel) support for &os; Max Khon fjoe@FreeBSD.org SVN repository Official Announcement

A module for DAHDI support for &os; has been created in the official Asterisk SVN repository.

The following drivers are currently ported:

The following HW drivers are currently ported and tested:

The port for dahdi_dynamic_eth and dahdi_dynamic_ethmf is under way.

More HW drivers need to be ported.

Please let me know if you can provide remote access with serial console to any box with ISDN/T1/E1 HW not currently supported by DAHDI for &os; but supported by DAHDI for Linux. I am also interested in porting drivers for FXO/FXS cards. Please let me know if you can provide a remote access or donate a card.

 CAM-based ATA implementation Alexander Motin mav@FreeBSD.org Scott Long scottl@FreeBSD.org

Existing ata(4) infrastructure, which has been around many years has various problems and limitations, with respect to modern controllers/devices support. A CAM subsystem (used for SCSI), which has been around for almost the same time, implements many of the algorithms required to solve many problems in a better way. To reduce code duplication and better support border cases such as ATAPI and SAS, new CAM based ATA implementation has been started in order to use its benefits.

As such, CAM infrastructure has been extended to support different transports. New transport has been implemented to support PATA/SATA buses. To support ATA disks, new CAM driver ada has been written. ATAPI devices are supported by existing SCSI drivers cd, da, sa, etc. To support SATA port-multipliers new CAM driver pmp has been written. To support most featured and widespread SATA controllers, new drivers ahci(4) and siis(4) have been developed.

To support legacy ATA controllers, kernel option ATA_CAM has been added. When used, it makes all ata(4) controllers directly available to CAM, deprecating ata(4) peripheral drivers and external APIs. To make this possible, ata(4) code has been heavily refactored, making controller driver API stricter.

Command queuing support gives new ATA implementation up to double performance benefit on some workloads, whereas 20-30% is quite usual.

SATA Port Multipliers support makes it easy to build fast and cheap storages with huge capacities, by using dozens of SATA drives in one system or external enclosures,

Some of that code has been presented in the recently released &os; 8.0-RELEASE but 8-STABLE includes much improved version now.

Improve timeouts and transport errors recovery.

Improve hot-plug support.

Search and fix any show stoppers for legacy ata(4) deprecation.

Write new, more featured driver for Marvell SATA controllers (specifications desired).

Write SAS-specific transport and drivers for SAS HBAs (specifications desired). SAS controllers can support SATA devices and multipliers, so it should fit nicely into the new infrastructure.

 Chromium web browser Ben Laurie ben@links.org test builds and port progress first build information

Chromium is a Webkit-based web browser that is largely BSD licensed. We have ported it from Linux to &os; in October and have been posting patches and test builds periodically since then. Chromium works well on &os; — it is very fast and stable, but there are a handful of rough edges that need to be polished up. Two remaining bugs should probably be fixed before releasing a chromium-devel port. We are looking for volunteers to test and maintain this port, to make this BSD browser a viable option on &os; desktop systems.

Fix sporadic rendering freezes Fix JavaScript interpreter, v8, on i386 architecture SUJ: Journaled SoftUpdates Jeff Roberson - jeff@freebsd.org + jeff@FreeBSD.org

I have been adding a small intent log to SoftUpdates to eliminate the requirement for fsck after an unclean shutdown. This work has been funded by Yahoo!, iXsystems, and Juniper. Kirk McKusick has been aiding me with design critiques and helping me better understand SoftUpdates.

Extensive testing by myself and Peter Holm has yielded a stable patch. Current users are encouraged to follow the instructions posted to the current@FreeBSD.org mailing list to verify stability in your own workloads. Updates are forthcoming and it is expected to be merged with current before the end of January. Ports to older versions of &os; will be available in SVN under alternate branches. Official backports will be decided by re@ when 9.0-CURRENT is stable.

The changes are fully backwards and forwards compatible as there are very few metadata changes to the filesystem. The journal may be enabled or disabled on existing FFS filesystems using tunefs(8). The log consumes 64 MB of space at maximum and fsck time is bounded by the size of the log rather than the size of the filesystem. Other details are available in my technical journal.

 Ports Collection Mark Linimon linimon@FreeBSD.org - The &os; Ports + The &os; Ports Collection + href="http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/"> Contributing to the &os; Ports Collection &os; ports monitoring system - The &os; + The &os; Ports Management Team marcuscom Tinderbox

Most of the recent activity has been dealing with the 8.0-RELEASE process. As an experiment, we have tried to decouple the ports QA timeline as much as possible from the src QA timeline. Although this meant that the impact on people actively maintaining and using ports has been much less than in previous releases, it still has not solved the problem of the release going out with a stale set of packages. We are still trying to come up with a better solution for the problem.

The ports count is over 21,000. The PR count jumped to over 1000, but is now back to around 950.

We are currently building packages for amd64-6, amd64-7, amd64-8, i386-6, i386-7, i386-8, i386-9, ia64-8, sparc64-7, and sparc64-8. This represents the addition of i386-9 and ia64-8 since the last report.

There has been some discussion of when to drop regular package builds for 6.X but no decision has been made yet. The cluster and the port managers are struggling to keep up with so many branches being active all at the same time.

Mark Linimon continues to make progress on the cluster nodes. Almost every node that does not have a hard disk failure is now online. In addition, he continues to make progress debugging problems that occasionally take nodes offline.

The next task is to characterize the overall performance of the build cluster. The question has been asked of us, "what would it take to speed up package builds?" There is no one simple answer. It is not merely a matter of having a larger number of package building machines -- before asking for funding we first need to identify the current bottlenecks. While we are starting to understand the problems on the nodes, the problems on the dispatch machine itself are much harder. Complicating the matter is that there are several periodic processes (ZFS backup, ZFS expiration, and errorlog compression, among others) that can combine to slow that machine significantly. The simultaneous interaction of all these is proving difficult to quantify.

Between Pav Lucistnik and Martin Wilke, many more experimental ports runs have been completed and committed.

We have added 3 new committers since the last report, and 1 older one has rejoined us.

We are still trying to set up ports tinderboxes that can be made available to committers for pre-testing. Most of the remaining ports PRs are "existing port/PR assigned to committer". Although the maintainer-timeout policy is helping to keep the backlog down, we are going to need to do more to get the ports in the shape they really need to be in. Although we have added many maintainers, we still have more than 4,700 unmaintained ports. (See, for instance, the list on portsmon. The percentage remains steady at just over 22%.) We are always looking for dedicated volunteers to adopt at least a few unmaintained ports. As well, the packages on amd64 and especially sparc64 lag behind i386, and we need more testers for those. &os;/sparc64 Marius Strobl marius@FreeBSD.org

The main thing that has taken place since the last Status Report is that I have gotten to the bottom of the remaining PCI problems with Sun Fire V215/V245 and support for these has been completed and since r202023 now is part of 9.0-CURRENT. With some luck it will also be part of the upcoming 7.3-RELEASE.

In other news:

 3G USB support Andrew Thompson thompsa@FreeBSD.org

Recently, a bunch of new device IDs have been added for the u3g(4) cellular wireless driver, the list should be comparable now with other operating systems around. A lot of these devices have a feature where the unit first attaches as a disk or CD-ROM that contains the Win/Mac drivers. This state should be detected by the u3g driver and the usb device is sent a command to switch to modem mode. This has been working for quite some time but as it is implemented differently for each vendor I am looking for feedback on any units where the auto switchover is not working (or the init is not recognized at all). Please ensure you are running an up to date kernel from 9.0-CURRENT r201681 or later, or 8-STABLE if r201681 has been merged by the time of publication.

 The &os; German Documentation Project Johann Kois jkois@FreeBSD.org Benedict Reuschling bcr@FreeBSD.org Martin Wilke miwi@FreeBSD.org German Documentation Project Homepage

We are happy to announce that Benedict Reuschling is now free from mentorship and can commit to the documentation tree on his own.

Since the last status report, the German Documentation Team has chased updates to various sections of the &os; Handbook, FAQ and the German website. Many handbook pages have been updated to the latest version, including chapters about configuration, disks, kernel configuration, printing, multimedia and virtualization.

We require help from volunteers that are willing to contribute bug fixes or translations. The following documents need active maintainership and are a good training ground for those willing to join the translation team:

Read the translations and report bugs to de-bsd-translators@de.FreeBSD.org. Translate articles or missing sections listed above. - The FreeBSD Spanish Documentation Project + The &os; Spanish Documentation Project Gábor Kövesdán gabor@FreeBSD.org - http://www.freebsd.org/doc/es/articles/fdp-es/ + Introduction to the Spanish Documentation Project - https://listas.es.freebsd.org/mailman/listinfo/doc + Translators' Mailing List

There is one article translation pending review. Apart from this, neither translations nor maintainance work have been done. We need more volunteers, mostly translators but we are glad to have more reviewers, as well. One can join by simply subscribing to the translators' mailing list where all the work is done.

Update Handbook translation Update webpage translation Add more article translations - The FreeBSD Hungarian Documentation Project + The &os; Hungarian Documentation Project Gábor Kövesdán gabor@FreeBSD.org Gábor Páli pgj@FreeBSD.org - Hungarian Web Page for FreeBSD + Hungarian Web Page for &os; - Hungarian Documentation - for FreeBSD + Hungarian Documentation + for &os; The - FreeBSD Hungarian Documentation Project's Wiki Page + &os; Hungarian Documentation Project's Wiki Page - Perforce - Depot for the FreeBSD Hungarian Documentation Project + Perforce + Depot for the &os; Hungarian Documentation Project

In the last months, no new translation has been added. Lacking human resources, we can only manage to keep the existing documentation and web page translations up to date. If you are interested in helping us, please contact us via the the email addresses noted above.

Translate release notes Add more article translations The &os; Forums &os; Forums Admins forum-admins@FreeBSD.org &os; Forums Moderators forum-moderators@FreeBSD.org - +

Since the last report we have seen a growth of 2,000 users on our forums resulting in approximately 10,000 registered users at this time. The posts count is about to reach 60,000 soon, which are contained in almost 9,000 threads.

The sign-up rate still hovers between 50-100 each week. The total number of visitors (including 'guests') is currently hard to gauge, but is likely to be a substantial multiple of the registered userbase.

New topics and posts are actively 'pushed out' to search engines. This in turn makes the forums show up in search results more and more often, making it a valuable and very accessible source of information for the &os; community.

One of the contributing factors to the forums' success is their 'BSD-style' approach when it comes to administration and moderation. The forums have a strong and unified identity and are very actively moderated, spam-free, and with a core group of very active and helpful members, dispensing many combined decades' worth of knowledge to starting, intermediate and professional users of &os;.

 V4L support in Linux emulator J.R. Oldroyd fbsd@opal.com

V4L video support in the Linux emulator is now available.

This work allows Linux applications using V4L video calls to work with existing &os; video drivers that provide V4L interfaces. It is tested and working with the net/skype port and also with browser-based Flash applications that access webcams. It is tested on &os;-8.0/amd64 and &os;-7.2/i386. An early version has been committed to 9.0-CURRENT and work is in progress to commit the latest version and then MFC.

Note: to be clear, this does not add V4L support to all webcams. The &os; camera driver must already offer V4L support itself in order for a Linux application to be able to use that camera. The multimedia/pwcbsd port provides the pwc(4) driver that already has V4L support. If your camera is supported by a different driver, you will need to enhance that driver to add V4L support.

 webcamd Hans Petter Selasky hselasky@FreeBSD.org

The webcamd daemon enables hundreds of different USB based webcam devices to be used under the &os;-8/9 operating system. The webcam daemon is basically an application, which is a port of Video4Linux USB webcam drivers into userspace on &os;. The daemon currently depends on libc, pthreads, libusb and the VIDEO4BSD kernel module.

Add support for the remaining Video4Linux USB devices. Make patches for increased buffer sizes, due to higher latency in userspace. Especially for High Speed USB. Group Limit Increase Brooks Davis - brooks@freebsd.org + brooks@FreeBSD.org

Historically, &os; has limited the number of supplemental groups per process to 15 (NGROUPS_MAX was incorrectly declared to be - 16). In FreeBSD 8.0-RELEASE we raised the limit to 1023, which should be + 16). In &os; 8.0-RELEASE we raised the limit to 1023, which should be sufficient for most users and will be acceptably efficient for incorrectly written applications that statically allocate NGROUPS_MAX + 1 entries.

Because some systems such as Linux 2.6 support a larger group limit, we have further relaxed this restriction in 9.0-CURRENT and made kern.ngroups a tunable value, which supports values between 1023 and INT_MAX - 1. We plan to merge this to 8-STABLE before 8.1-RELEASE.

 Syncing pf(4) with OpenBSD 4.5 Ermal Luçi eri@FreeBSD.org - + Viewing the changes. - The + The actual repo to build from.

This import is based on OpenBSD 4.5 state of pf(4). It includes many improvements over the code currently present in &os;. The actual new feature present in pf45 repository is support for divert(4), which should allow tools like snort_inline to work with pf(4) too.

Currently, the pf(4) import is considered stable with normal kernel, as well as VIMAGE enabled kernels.

pflow(4)/pflog(4)/pfsync(4) need to be made VIMAGE aware. More regression testing is needed. - + NFSv4 ACL support Edward Tomasz Napierala trasz@FreeBSD.org - +

Native NFSv4 ACL support in ZFS and UFS has been committed into 9.0-CURRENT. It - is expected to be MFCed in order to make it into FreeBSD 8.1-RELEASE.

+ is expected to be MFCed in order to make it into &os; 8.1-RELEASE.

Support for NFSv4 ACLs in tar(1). MFC. Ralink wireless RT2700U/2800U/3000U run(4) USB driver Akinori Furukoshi moonlightakkiy@yahoo.ca - + Announcement on the &os; Forums

The run(4) driver brings support for Ralink RT2700U/2800U/3000U USB wireless devices. For detailed information and list of all the supported devices, please see the above mentioned URL. The source code has been imported to the USB P4 repository on January 10, 2010 (172906).

Solve USB_TIMEOUT problem when sending beacons, and/or confirm which chipsets supports AP mode if all of them don't support it. Read TX stats for AMRR on AP mode, and/or confirm which chipsets supports AP mode if all of them don't support it. Maintain the code. &os;/mips The &os;/mips mailing list mips@FreeBSD.org Warner Losh imp@FreeBSD.org - + - +

The base/projects/mips branch has been merged into 9.0-CURRENT. The merge is complete and the sanity tests have passed. The code has booted on both a Ubiquiti RouterStation (big endian) as well as in gxemul (little endian).

The branch lived for one year, minus a day, and accumulated much work:

  • A new port to the Atheros AR71xx series of processors. This port supports the RouterStation and RouterStation PRO boards from Ubiquiti. Other boards should work with minimal tweaking. This port should be considered as nearing production quality, and has been used extensively by the developers. The primary author of this port is Oleksandr Tymoshenko (gonzo@FreeBSD.org).
  • A new port to the sibyte BCM1250 SoC on the BCM91250 evaluation board (aka SWARM). This port is reported to be stable, but this hardware is a little old and not widely available. The primary author of this port is Neel Natu (neel@FreeBSD.org). Only one core is presently supported.
  • A port, donated by Cavium, to their Octeon and Octeon plus series of SoC (CN3xxx and CN5xxx). This code is preliminary, supporting only a single core right now. It has been lightly tested on the CN3860 evaluation board only in 32-bit mode. Warner Losh (imp@FreeBSD.org) has been driving the efforts to get this code into the tree.
  • A port, donated by RMI, to their XLR series of SoCs. This port is single core only, as well. The code reaches multi-user but should be considered beta quality for the moment. Randal Stewart (rrs@FreeBSD.org) has been driving the efforts to integrate this into the tree.
  • Preliminary support for building a mips64 kernel from this source base. More work is needed here, but at least two kernels successfully build in 64-bit mode (OCTEON1 and MALTA64).
  • Very early support for N32 and N64 ABIs
  • Support for booting compressed kernels has been added (gonzo@).
  • Improved support for debugging
  • Improved busdma and bus_space support
  • Many bug fixes
  • More types of MIPS cores are recognized
  • Expanded cache handling for newer processors
  • Beginning of a port to the alchemy au1XXX cpus is present, but experimental.
  • Work on SMP is underway to support multicore processors like the sibyte, Octeon and XLR processors.

The development branch had been updated incorrectly several times over the past year, and the damage was too much to repair. We've retired the branch and will do further mips development in 9.0-CURRENT for the time being. If you have a checked out tree, the suggested way to update the projects/mips tree you have is to do a "svn switch - svn://svn.freebsd.org/base/head" in that tree.

+ svn://svn.FreeBSD.org/base/head" in that tree.

I would like to thank everybody that has contributed time, code - or hardware to make FreeBSD/mips better.

+ or hardware to make &os;/mips better.

As development proceeds, I will keep posting updates. In addition, I hope to have some mini "how-to" wiki pages done for people that want to try it out.

We are still investigating how feasible merging all this work into 8-STABLE will be, as it represents a huge leap forward in code stability and quality. - Flattened Device Tree for embedded FreeBSD + Flattened Device Tree for embedded &os; Rafal Jaworowski raj@semihalf.com - Project wiki pages + Project wiki pages - Project P4 branch + Project P4 branch

The purpose of this project is to provide &os; with support for the Flattened Device Tree (FDT) technology, the mechanism for describing computer hardware resources, which cannot be probed or self enumerated, in a uniform and portable way. The primary consumer of this technology are - embedded FreeBSD platforms (ARM, AVR32, MIPS, PowerPC), where a lot of + embedded &os; platforms (ARM, AVR32, MIPS, PowerPC), where a lot of designs are based on similar chips but have different assignment of pins, memory layout, addresses bindings, interrupts routing and other resources.

Current state highlights:

  • Environment, supported tools
    • Integrated device tree compiler (dtc) and libfdt into &os; userspace, kernel and loader build
  • loader(8)
    • Full support for device tree blob handling
    • Load, traverse, modify (including add/remove) device tree nodes and properties
    • Pass the device tree blob to the kernel
    • Both ARM and PowerPC loader(8) supported
  • Kernel side FDT support (common)
    • Developed OF interface for FDT-backed platforms
    • ofw_bus I/F (and /dev/openfirm) available with FDT
    • Integrated FDT resources representation with newbus (fdtbus and simplebus drivers)
  • PowerPC kernel (Freescale MPC85XX SOC)
    • MPC8555CDS and MPC8572DS successfully converted to FDT conventions
  • ARM kernel (Marvell Orion, Kirkwood and Discovery SOC)
    • Work in progress on integrating FDT infrastructure with ARM platform code
-

Work on this project has been sponsored by the FreeBSD Foundation.

+

Work on this project has been sponsored by the &os; Foundation.

Complete missing pieces for PowerPC (PCI bridge driver conversion to FDT) Complete ARM support Merge to SVN - HAST - Highly Available Storage Pawel Jakub Dawidek pjd@FreeBSD.org + href="http://lists.FreeBSD.org/pipermail/freebsd-announce/2009-October/001279.html"> Announcement

HAST software will provide synchronous replication of any GEOM provider (eg. disk, partition, mirror, etc.) or file from one &os; machine (primary node) to another one (secondary node).

Because data is replicated on block level neither application, no file systems have to be modified to take advantage of this functionality.

The functionality that HAST software will provide is very similar to the functionality provided by the DRBD project for Linux.

The HAST project is sponsored by the &os; Foundation.

Work is progressing well, first milestone was reached in December 2009 and the project completion date is January 31, 2010.

Check out &os; mailing lists for patches to test in February and wish me good luck!

And by the way, don't forget to donate to the &os; Foundation, as your donations make projects like this possible.

Thank you!

 - + Wireless mesh networking Rui Paulo rpaulo@FreeBSD.org - + -

Development of the FreeBSD 802.11s stack continues. The code in - FreeBSD HEAD has been updated to comply with draft 4.0. Merge to - FreeBSD 8-STABLE will be done soon.

+

Development of the &os; 802.11s stack continues. The code in + &os; HEAD has been updated to comply with draft 4.0. Merge to + &os; 8-STABLE will be done soon.

The developer is looking for funding to be able to implement mesh link security algorithms and/or coordinated channel access (performance improvement).

- - - FreeBSD TDM Framework + &os; TDM Framework Rafal Czubak rcz@semihalf.com Michal Hajduk mih@semihalf.com

Important changes regarding &os; TDM Framework since last Status Report:

  • Fully functional TDM controller driver for Marvell Kirkwood and Discovery SoCs.
  • Working voiceband channel character device driver.
  • Working Si3215, Si3050 codec drivers on corresponding FXS, FXO ports.
  • Demo application, which is capable of manipulating voiceband channel and codec state, starting/stopping channel transfers and echoing on single channel.
  • Preliminary version of driver bridging the voiceband infrastructure with Zaptel/DAHDI.
Improve various issues regarding working drivers and demo application. Test Si3050 codec driver operation with PSTN. Fully integrate voiceband infrastructure with Zaptel/DAHDI telephony hardware drivers. - POSIX utmpx for FreeBSD + POSIX utmpx for &os; Ed Schouten ed@FreeBSD.org - POSIX specification. + Announcement + + POSIX specification - NetBSD's implementation. + NetBSD's implementation - OpenSolaris's implementation. + OpenSolaris's implementation

On January 13, I removed the utmp user accounting database and - replaced it by POSIX utmpx. Unfortunately, the upgrade path is a bit + replaced it with POSIX utmpx. Unfortunately, the upgrade path is a bit bumpy, because the utmp interface provided almost no library interface to interact with the database files.

This change may have caused some regressions. Some ports may fail to build, while there could also be bugs in the library functions.

Get a list of broken ports Fix them to comply to standards Send patches upstream BSD-licensed iconv Gábor Kövesdán gabor@FreeBSD.org - Sources in the Perforce repository + Sources in the Perforce repository

Good compatibility has been ensured and there are only few pending items, which have to be reviewed/enhanced. Recently, an enhancement has been completed, which makes it possible to accomplish better transliteration, just like in the GNU version. An initial testing patch is expected at the beginning of February.

Enhance conversion tables to make use of enhanced transliteration. A performance optimization might be done later. BSD-licensed text processing tools Gábor Kövesdán gabor@FreeBSD.org - Perforce repository + Perforce repository

As 8.0-RELEASE is out, BSD bc/dc can be now committed to 9.0-CURRENT. We are only waiting for an experimental package building to make sure there are no regressions after this change. BSD grep is complete but it cannot be integrated yet because of some regex library issues. We need first a fast and modern regex library so that we can change to BSD grep. BSD sort has few incomplete features and needs some performance review.

Commit BSD bc/dc Implement remaining features for sort and optimize performance + + + NVIDIA amd64 driver + + + + + John + Baldwin + + jhb@FreeBSD.org + + + + + Release Announcement + + + +

NVIDIA has released the first BETA version of its graphics + drivers for &os;/amd64. Note that this driver will work on &os; + versions 7.3 or 8.0 and later. It also works on very recent + versions of 7.2-STABLE. More details are provided in the + official release announcement.

+ +