diff --git a/en/news/status/report-2009-10-2009-12.xml b/en/news/status/report-2009-10-2009-12.xml index 0379a07bbc..4404719f56 100644 --- a/en/news/status/report-2009-10-2009-12.xml +++ b/en/news/status/report-2009-10-2009-12.xml @@ -1,1436 +1,1436 @@ - + October-December 2009
Introduction

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

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

+ happy and successful new year 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 the 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 number of problems and limitations, in respect to modern controllers/devices support. A CAM subsystem (used for SCSI), which is around for almost the same time, implements many of required algorithms solving 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 was extended to support different transports. New transport was implemented to support PATA/SATA buses. To support ATA disks, new CAM driver ada was written. ATAPI devices are supported by existing SCSI drivers cd, da, sa, etc. To support SATA port-multipliers new CAM driver pmp was written. To support most featured and widespread SATA controllers, new drivers ahci(4) and siis(4) were developed.

To support legacy ATA controllers, kernel option ATA_CAM was added. When used, it makes all ata(4) controllers directly - available to CAM, deprecating ata(4) periperal drivers and external + available to CAM, deprecating ata(4) peripheral drivers and external APIs. To make it possible, ata(4) code was heavily refactored, making controller driver API more strict.

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 was presented in &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 (specs wanted).

Write SAS-specific transport and drivers for SAS HBAs (specs wanted). 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 ported it from linux to &os; in October and have been posting patches and test builds periodically ever since. 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 the &os; desktop.

Fix sporadic rendering freezes Fix javascript interpreter, v8, on i386 architecture SUJ: Journaled Softupdates Jeff Roberson 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 current@ 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 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 megabytes 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 Collection Contributing to the &os; Ports Collection &os; ports monitoring system The &os; Ports Management Team marcuscom Tinderbox

Most of the recent activity was dealing with the 8.0 release process. As an experiment, we 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 was much less than in previous releases, it still has not solved the problem of the release going out with an 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 portmgrs, 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 interaction of all these simultaneously is proving difficult to quantify.

Between pav and miwi, 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.

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 HEAD. 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 with other operating systems around. A lot of these devices have a feature where the unit first attaches as a disk or cdrom 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 its 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 head r201681 or later, or stable/8 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 doc-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 were updated to the latest version, including chapters about configuration, disks, kernel configuration, printing, multimedia and virtualization.

We require help from volunteers who 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 Gábor Kövesdán gabor@FreeBSD.org http://www.freebsd.org/doc/es/articles/fdp-es/ https://listas.es.freebsd.org/mailman/listinfo/doc

There is one article translation pending review. Apart from this, neither translation nor maintainance work has 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 Gábor Kövesdán gabor@FreeBSD.org Gábor Páli pgj@FreeBSD.org Hungarian Web Page for FreeBSD Hungarian Documentation for FreeBSD The FreeBSD Hungarian Documentation Project's Wiki Page Perforce Depot for the FreeBSD Hungarian Documentation Project

In the last months, no new translation has been added. Lacking human resources, we can only manage the existing documentation and web page translations. 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 2000 users on our Forums resulting in ca. 10.000 registered users at this time. The posts count is about to reach 60.000 soon, which are contained in almost 9000 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 apps that access webcams. It is tested on &os;-8.0/amd64 and &os;-7.2/i386. An early version has been committed to head 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 app 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

Historically, FreeBSD has limited the number of supplemental groups per process to 15 (NGROUPS_MAX was incorrectly declared to be 16). In FreeBSD 8.0 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 -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 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 was merged into HEAD. It is expected to be MFCed in order to make it into FreeBSD 8.1.

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 base/head. 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:

I am sure there are minor items I have forgotten. If so, please forgive any omission on my part...

he 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 "head" 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.

I would like to thank everybody that has contributed time, code or hardware to make FreeBSD/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 stable/8 will be, as it represents a huge leap forward in code stability and quality. Flattened Device Tree for embedded FreeBSD Rafal Jaworowski raj@semihalf.com Project wiki pages Project P4 branch

The purpose of this project is to provide FreeBSD 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 designs are based on similar chips, but have different assignment of pins, memory layout, addresses bindings, interrupts routing and other resources.

Current state highlights:

-

Work on this project is sponsored by the FeeBSD Foundation.

+

Work on this project is sponsored by the FreeBSD 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 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 31st 2010.
Check out &os; mailing lists for patches to test in February and wish me good luck!
And BTW, 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.

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 Rafal Czubak rcz@semihalf.com Michal Hajduk mih@semihalf.com

Important changes regarding FreeBSD TDM Framework since last Status Report:

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. utmpx for FreeBSD Ed Schouten ed@FreeBSD.org POSIX specification. NetBSD'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 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

Good compatibility has been ensured and there are only few pending - items, which have to be reviewed/enhanced. Recently, an enhacement + 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

As 8.0-RELEASE is out, BSD bc/dc can be now committed, we are only waiting for the portbuild exp-run to make sure there are no regressions after this change. BSD grep is stalled 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