<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status
Report//EN" "http://www.FreeBSD.org/XML/www/share/sgml/statusreport.dtd">
<!-- $FreeBSD$ -->
<report>
  <date>
    <month>October-December</month>

    <year>2011</year>
  </date>

  <section>
    <title>Introduction</title>

    <p>This report covers &os;-related projects between October and
      December 2011.  It is the last of the four reports planned for 2011.
      This quarter was mainly devoted to polishing the bits for the next
      major version of &os;, 9.0, which was already successfully released in
      the beginning of January 2012.</p>

    <p>Thanks to all the reporters for the excellent work! This report
      contains 32 entries and we hope you enjoy reading it.</p>

    <p>Please note that the deadline for submissions covering the period
      between January and March 2012 is April 15th, 2012.</p>
  </section>

  <category>
    <name>proj</name>

    <description>Projects</description>
  </category>

  <category>
    <name>bin</name>

    <description>User-land Programs</description>
  </category>

  <category>
    <name>team</name>

    <description>&os; Team Reports</description>
  </category>

  <category>
    <name>kern</name>

    <description>Kernel</description>
  </category>

  <category>
    <name>docs</name>

    <description>Documentation</description>
  </category>

  <category>
    <name>arch</name>

    <description>Architectures</description>
  </category>

  <category>
    <name>ports</name>

    <description>Ports</description>
  </category>

  <project cat='ports'>
    <title>&os; Ruby Ports</title>

    <contact>
      <person>
	<name>
	  <given>Philip</given>
	  <common>Gollucci</common>
	</name>
	<email>pgollucci@FreeBSD.org</email>
      </person>

      <person>
	<name>
	  <given>Steve</given>
	  <common>Wills</common>
	</name>
	<email>swills@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://wiki.FreeBSD.org/Ruby">Wiki</url>

      <url href="http://people.FreeBSD.org/~pgollucci/FreeBSD/prs/prefixes.html#ruby-">
	PRs</url>

      <url href="http://people.FreeBSD.org/~pgollucci/FreeBSD/prs/prefixes.html#rubygem-">
	PRs</url>
    </links>

    <body>
      <p>Work is underway to convert the remaining ruby- ports to
	rubygem-* ports in order to keep up with the gem community.</p>

      <p>A second attempt will be made to change the default ruby from
	1.8 to 1.9.  There will be some unavoidable casualties of this
	transition.  The sysutils/rubygem-chef-server port was contributed by
	RideCharge Inc / Taxi Magic who is now using it exclusively.</p>
    </body>

    <help>
      <task>Need some fresh -exp runs to check the new status especially with
	ruby 1.9.3-p0.</task>
    </help>
  </project>

  <project cat='proj'>
    <title>BSD-Licensed C++ Stack</title>

    <contact>
      <person>
	<name>
	  <given>David</given>
	  <common>Chisnall</common>
	</name>
	<email>theraven@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>Two new libraries, libc++ (providing a C++11 STL implementation)
	and libcxxrt (providing an implementation of the C++ ABI
	specification) have been added.  This is enabled by adding
	WITH_LIBCPLUSPLUS=yes to src.conf.  It is not enabled by default
	because libc++ does not build with the version of gcc in the base
	system and requires you to build with clang.</p>

      <p>Once it is built, you can select between using GNU libstdc++ and
	libc++ by adding -stdlib=libc++ or -stdlib=libstdc++ to your
	compile and link flags (when building with clang).</p>

      <p>If you are running head (or have a spare [virtual] machine you
	can try it on) then please try building your C++ code with libc++
	and let me know of any failures, ideally with reduced test
	cases.</p>
    </body>

    <help>
      <task>Test ports with libc++.  Hopefully most will Just Work., but
	others may need patches or have a hard dependency on
	libstdc++.</task>

      <task>Make libstdc++ dynamically link to libsupc++.  This will allow
	us to use libmap.conf to switch between libsupc++ and
	libcxxrt.</task>

      <task>Enable building libc++ by default (hopefully in the 9.1
	time-frame, when clang becomes the default system compiler) and
	switch to using libcxxrt instead of libsupc++ by default.</task>

      <task>Lots more testing.  Followed by even more testing.</task>

      <task>Removing libstdc++ from the base system and making it
	available through ports for backwards compatibility.</task>
    </help>
  </project>

  <project cat='kern'>
    <title>GEOM MULTIPATH Rewrite</title>

    <contact>
      <person>
	<name>
	  <given>Alexander</given>
	  <common>Motin</common>
	</name>
	<email>mav@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://people.FreeBSD.org/~mav/gmultipath5.patch">Patch
	committed into the HEAD.</url>
    </links>

    <body>
      <p>The GEOM MULTIPATH class underwent a major rewrite to fix many
	problems and improve functionality, including:</p>

      <ul>
	<li>Improved locking and destruction process to fix crashes.</li>

	<li>"Automatic" configuration method improved to make it safe by
	  reading metadata back from all specified paths after writing to
	  one.</li>

	<li>"Manual" configuration method added to work without using
	  on-disk metadata.  New "add" and "remove" commands allow to manage
	  paths manually.</li>

	<li>Failed paths are no longer dropped from GEOM, but only marked
	  as failed and excluded from I/O operations.  Failed paths can be
	  automatically restored when all other paths are lost or marked as
	  failed, for example, because of device-caused (not transport)
	  errors. "Fail" and "restore" commands added to manually control
	  failure status.</li>

	<li>Added Active/Active mode support.  Unlike the default
	  Active/Passive mode, the load is evenly distributed between all
	  working paths.  If supported by the device, it allows to
	  significantly improve performance, utilizing bandwidth of all
	  paths.  It is controlled by the -A option during creation.</li>

	<li>Provider size check added to reduce chance of conflict with
	  other GEOM classes.</li>

	<li>GEOM is now destroyed on last provider disconnection.</li>

	<li>`status` and `list` commands output was improved.</li>
      </ul>

      <p>These changes are now committed into the &os; HEAD branch.  Merge
	to 9-STABLE and 8-STABLE is planned after 9.0 release.</p>

      <p>Project sponsored by iXsystems, Inc.</p>
    </body>

    <help>
      <task>Implement some additional request ordering mechanism for the
	Active/Active mode.  Some consumers in theory may not wait for
	previous requests completion before submitting new overlapping or
	dependent requests.  Those requests may be reordered on device if
	run via different paths simultaneously.</task>
    </help>
  </project>

  <project cat='docs'>
    <title>A Tool to Check for Mistakes in Documentation &mdash; igor</title>

    <contact>
      <person>
	<name>
	  <given>Warren</given>
	  <common>Block</common>
	</name>
	<email>wblock@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.wonkity.com/~wblock/igor/" />
    </links>

    <body>
      <p>igor is a program that proofreads man pages, DocBook SGML
	source, and other text files for many common mistakes.</p>

      <p>Files are tested for spelling mistakes, repeated words, and
	white-space problems.  Man pages are also checked for minimal
	structure, and DocBook SGML source files are checked for formatting
	and tag problems.</p>

      <p>If you write or edit &os; documentation, let igor help you check
	it for correctness.</p>
    </body>

    <help>
      <task>Find a testing or parsing framework that can do a faster or
	better job, or that can understand the state of DocBook
	tags.</task>

      <task>Add more tests.</task>

      <task>Improve speed.</task>
    </help>
  </project>

  <project cat='kern'>
    <title>The New CARP</title>

    <contact>
      <person>
	<name>
	  <given>Gleb</given>
	  <common>Smirnoff</common>
	</name>
	<email>glebius@FreeBSD.org</email>
      </person>

      <person>
	<name>
	  <given>Bjoern</given>
	  <common>Zeeb</common>
	</name>
	<email>bz@FreeBSD.org</email>
      </person>

      <person>
	<name>
	  <given>George</given>
	  <common>Neville-Neil</common>
	</name>
	<email>gnn@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://svnweb.FreeBSD.org/base?view=revision&amp;revision=228571">
	The main commit</url>
    </links>

    <body>
      <p>Significantly updated CARP protocol has been committed to head/.
	I expect the new code to be easier to maintain and less buggy,
	since it uses less hacks in the networking stack.</p>

      <p>The new CARP does not bring a lot of new features, however here
	is a couple:</p>

      <ul>
	<li>One can put a single redundant address on an interface.</li>

	<li>Master/backup state can be switched via ifconfig.</li>

	<li>Feature that demotes carp(4) during pfsync(4) update has been
	  restored (it was lost in 7.0).</li>

	<li>The overall ifconfig(8) output is now more readable, since
	  addresses are exactly on the interfaces they are running.  Yes,
	  this is feature, too :)</li>
      </ul>

      <p>The code has been developed by glebius@ with lots of help from
	bz@.</p>
    </body>

    <help>
      <task>Work on arpbalance/ipbalance features.  Since I do not utilize
	them at all, first I need to find somebody eager to see these
	features and willing to test patches.  Sponsoring work is also
	appreciated.  glebius@ to handle.</task>

      <task>Estimate whether we need to catch up with OpenBSD on putting
	demotion counter into datagrams.  glebius@ to handle.</task>

      <task>Update tcpdump(8) to enable nice printing of CARP packets.
	gnn@ to handle.</task>

      <task>Work with IANA to get an official protocol number.  gnn@ to
	handle.</task>
    </help>
  </project>

  <project cat='arch'>
    <title>&os;/390</title>

    <contact>
      <person>
	<name>
	  <given>Pau</given>
	  <common>Amma</common>
	</name>
	<email>fduuvrzv@yahoo.com</email>
      </person>

      <person>
	<name>
	  <given>Bjoern A.</given>
	  <common>Zeeb</common>
	</name>
	<email>bz@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>I wandered in and started working on &os;/390 about 1 month ago
	based on source Bjoern provided.  My short term goals are to sync it
	with the current HEAD and write a minimal IPLabel loader, so we do
	not have to depend on Hercules-only commands to test the kernel
	boot process.</p>

      <p>Then it will be time to make the crossbuild work again and get
	the kernel booting.</p>
    </body>
  </project>

  <project cat='bin'>
    <title>System Configuration Utilities</title>

    <contact>
      <person>
	<name>
	  <given>Devin</given>
	  <common>Teske</common>
	</name>
	<email>dteske@vicor.com</email>
      </person>
    </contact>

    <links>
      <url href="http://druidbsd.sourceforge.net/">The DruidBSD
	Project</url>
    </links>

    <body>
      <p>On December 31st, 2011 sysutils/sysrc was added to the
	ports-tree.  On January 6th, 2012 sysutils/host-setup was added to
	the ports-tree.  Still pending is the addition of
	sysutils/tzdialog.</p>

      <p>Together or separately, these utilities try to make configuring
	the system easier and more efficient.</p>

      <p>sysrc(8) allows you to safely modify rc.conf(5) without fear or
	trepidation; making remote-management and scripted changes a simple
	transaction.  Also useful in managing puppet installations.</p>

      <p>host-setup(8) allows you to configure your time zone, hostname,
	network interfaces, default router/gateway, DNS nameservers in
	resolv.conf(5) all via dialog(1) (or Xdialog(1)) interface.
	Designed to replace sysinstall(8), host-setup is written entirely
	in sh(1) and is completely stand-alone.</p>

      <p>tzdialog(8) is an ISO-3166 compatible sh(1) rewrite of
	tzsetup(8).  It is designed to be a drop-in replacement for tzsetup.
	The major difference between the two is tzdialog(8) adds supports
	for graphical user interface via Xdialog(1) (by passing the `-X'
	argument), whereas tzsetup(8) only supports console-based
	interaction.</p>
    </body>

    <help>
      <task>Write a man-page for tzdialog(8).</task>

      <task>Submit current tzdialog(8) version (1.1) and yet-to-be
	completed man-page to ports-tree as sysutils/tzdialog.</task>
    </help>
  </project>

  <project cat='ports'>
    <title>Perl Ports Testing</title>

    <contact>
      <person>
	<name>
	  <given>Steve</given>
	  <common>Wills</common>
	</name>
	<email>swills@FreeBSD.org</email>
      </person>

      <person>
	<name>
	  <given>Sunpoet Po-Chuan</given>
	  <common>Hsieh</common>
	</name>
	<email>sunpoet@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>Many Perl modules in ports come with test cases included with
	their source.  This project's goal is to ensure that all these tests
	pass.  Patches have been added to the ports tinderbox to allow test
	related dependencies to be installed and many ports have
	TEST_DEPENDS now.  A patch is available to enable testing for those
	who wish to help out.  All p5- ports have been built and tests
	attempted.  Approximately 61% of the Perl ports pass currently.  Many
	ports have been updated to include missing dependencies or make
	other changes which allow tests to pass.  Long term goals include a
	more generic framework for testing ports and automated tests
	executed when ports are updated.</p>
    </body>

    <help>
      <task>Many Perl ports which do not pass tests remain.</task>

      <task>Need to figure out how to move testing out of
	tinderbox.</task>

      <task>A patch to build Perl with -pthread (but not enable
	useithreads in Perl) is pending.  It will fix many currently broken
	tests</task>
    </help>
  </project>

  <project cat='kern'>
    <title>Status Report for NFS</title>

    <contact>
      <person>
	<name>
	  <given>Rick</given>
	  <common>Macklem</common>
	</name>
	<email>rmacklem@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>The new NFS client and server are no longer considered
	experimental and are the default for &os; 9.0.  Included is fairly
	complete support for NFSv4.0, as well as NFSv3 and NFSv2.  NFSv4.0
	delegations are not enabled by default for the server, since there
	is no handling of them for local system calls done on the server,
	as yet.  So far, the transition seems to have gone alright, with only
	a couple of obscure issues identified that did not get fixed
	for &os; 9.0.  Patches for these can be found at
	<a href="http://people.FreeBSD.org/~rmacklem">
	  http://people.FreeBSD.org/~rmacklem</a>
      </p>

      <p>Work is ongoing with respect to NFSv4.1 client support.  The
	current code includes functioning support for the required
	components, in particular, sessions for both fore and back
	channels.  Development for the big optional component pNFS is in
	progress and will hopefully be functional for the Files layout in a
	few months.  The modified sources can be found at <a
	  href="http://svn.FreeBSD.org/viewvc/base/projects/nfsv4.1-client">
	  http://svn.FreeBSD.org/viewvc/base/projects/nfsv4.1-client</a>.</p>

      <p>There is also a patch for what I call packrats, where threads
	perform aggressive on-disk caching of delegated file in the NFSv4.0
	client.  It currently seems to function OK, but does not yet have
	client reboot recovery implemented, so it can only be used
	experimentally at this time.  This patch can be found at <a
	  href="http://people.FreeBSD.org/~rmacklem/packrat-patches">
	  http://people.FreeBSD.org/~rmacklem/packrat-patches</a>.</p>
    </body>
  </project>

  <project cat='docs'>
    <title>The &os; Japanese Documentation Project</title>

    <contact>
      <person>
	<name>
	  <given>Hiroki</given>
	  <common>Sato</common>
	</name>
	<email>hrs@FreeBSD.org</email>
      </person>

      <person>
	<name>
	  <given>Ryusuke</given>
	  <common>Suzuki</common>
	</name>
	<email>ryusuke@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.FreeBSD.org/ja/">Japanese &os; Web
	Pages</url>

      <url href="http://www.jp.FreeBSD.org/doc-jp/">The &os; Japanese
	Documentation Project Web Page</url>
    </links>

    <body>
      <p>During this period, many part of the outdated contents in the
	www/ja subtree were updated to the latest versions in the English
	counterpart.  The "bsdinstall" section in Handbook was newly
	translated and the "cutting-edge" section is now
	work-in-progress.</p>
    </body>

    <help>
      <task>Further translation work for outdated documents in both
	doc/ja_JP.eucJP and www/ja.</task>
    </help>
  </project>

  <project cat='ports'>
    <title>&os;/KDE</title>

    <contact>
      <person>
	<name>
	  <given>&os;</given>
	  <common>KDE</common>
	</name>
	<email>kde@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://FreeBSD.kde.org">&os;/KDE home page</url>

      <url href="http://FreeBSD.kde.org/area51.php">area51</url>
    </links>

    <body>
      <p>The KDE/&os; team have continued to improve the experience of
	KDE software and Qt under &os;.  The latest round of improvements
	include:</p>

      <ul>
	<li>Many fixes upstream to make KDE and Qt build with Clang</li>

	<li>Making automoc not freeze with parallel builds</li>
      </ul>

      <p>The team has also made many releases and upstreamed many fixes
	and patches.  The latest round of releases include:</p>

      <ul>
	<li>KDE SC: 4.7.3, 4.7.4 (in the area51 experimental
	  repository)</li>

	<li>Qt: 4.8.0 (in the area51 experimental repository)</li>

	<li>CMake: 2.8.6, 2.8.7</li>
      </ul>

      <p>The team is always looking for more testers and porters so
	please contact us at kde@FreeBSD.org and visit our home page at
	<a href="http://FreeBSD.kde.org">http://FreeBSD.kde.org</a>.</p>
    </body>

    <help>
      <task>Testing KDE SC 4.8.0.</task>

      <task>Testing KDE PIM 4.7.4.</task>

      <task>Testing phonon-gstreamer and phonon-vlc as the phonon-xine
	backend was deprecated (but will remain in the ports for
	now).</task>

      <task>Testing the Calligra beta releases (in the area51
	repository).</task>
    </help>
  </project>

  <project cat='ports'>
    <title>&os; Haskell Ports</title>

    <contact>
      <person>
	<name>
	  <given>G&aacute;bor J&aacute;nos</given>
	  <common>P&Aacute;LI</common>
	</name>
	<email>pgj@FreeBSD.org</email>
      </person>

      <person>
	<name>
	  <given>Ashish</given>
	  <common>SHUKLA</common>
	</name>
	<email>ashish@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://wiki.FreeBSD.org/Haskell">&os; Haskell wiki
	page</url>

      <url href="https://github.com/freebsd-haskell/freebsd-haskell/">
	&os; Haskell ports repository</url>

      <url href="http://haskell.org/mailman/listinfo/freebsd-haskell/">
	&os; Haskell mailing list</url>
    </links>

    <body>
      <p>We are proud to announce that the &os; Haskell Team has updated
	the Haskell Platform to 2011.4.0.0, as well as updated GHC to 7.0.4
	in &os; Haskell ports repository.  We also added a number of new
	Haskell ports, and their count is now more than 300.  Some of the
	new ports include Yesod, Happstack (popular web development
	frameworks in Haskell), ThreadScope (a graphical profiler tool for
	parallel Haskell programs).</p>

      <p>Due to ports repository freeze for 9.0-RELEASE, these updates
	are not in official ports tree yet.  They will be committed to the
	ports repository after it is unfrozen again, in the meantime
	they can be accessed through &os; Haskell ports repository.</p>
    </body>

    <help>
      <task>Commit pending Haskell ports to &os; ports repository.</task>

      <task>Test GHC to work with clang/LLVM.</task>

      <task>Add an option to the <tt>lang/ghc</tt> port to be able to
	build it with already installed GHC instead of requiring a
	separate GHC bootstrap tarball.</task>
    </help>
  </project>

  <project cat='ports'>
    <title>Public &os; Ports Development Infrastructure &mdash;
      redports.org</title>

    <contact>
      <person>
	<name>
	  <given>Bernhard</given>
	  <common>Froehlich</common>
	</name>
	<email>decke@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://redports.org/" />

      <url href="irc://irc.freenode.net#redports">IRC: #redports on
	Freenode</url>

      <url href="https://groups.google.com/group/redports">redports
	mailing list</url>

      <url href="http://redports.org/wiki/UserGuide">Userguide (with
	Screenshots)</url>
    </links>

    <body>
      <p>Redports is a free service for &os; port maintainers and port
	committers to automatically buildtest ports on various &os;
	versions and architectures.  The motivation to do that was because
	there are many people that do not have access to Ports Tinderboxes
	and the existing Tinderboxes are usually dedicated to a single
	team.</p>

      <p>The platform was designed with scalability in mind but building
	capacity is currently very limited until more hardware is
	available.  I am already in contact with the usual suspects to
	improve that.</p>
    </body>

    <help>
      <task>Get more Hardware for building.</task>

      <task>Port options support.</task>

      <task>ports-mgmt/portlint support.</task>
    </help>
  </project>

  <project cat='kern'>
    <title>HDA Sound Driver (snd_hda) Improvements</title>

    <contact>
      <person>
	<name>
	  <given>Alexander</given>
	  <common>Motin</common>
	</name>
	<email>mav@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://people.FreeBSD.org/~mav/hda.rewrite2.patch">
	Latest patch</url>
    </links>

    <body>
      <p>snd_hda(4) driver took major rewrite:</p>

      <ul>
	<li>Big old hdac driver was split into three independent pieces:
	  HDA controller driver (hdac), HDA CODEC driver (hdacc) and HDA
	  audio function driver (hdaa).  All drivers are completely
	  independent and talk to each other only via NewBus interfaces.
	  Using more NewBus bells and whistles allows to properly see HDA
	  structure with standard system instruments, such as `devinfo -v`.
	  Biggest driver file size now is 150K, instead of 240K before, and
	  the code is much cleaner.</li>

	<li>Support for multichannel recording was added.  While I have
	  never seen it configured by default, UAA specification tells that
	  it is possible.  Now, as specification defines, driver checks
	  input associations for pins with sequence numbers 14 and 15, and
	  if found (usually) &mdash; works as before, mixing signals together.
	  If it does not, it configures input association as multichannel.
	  I have found some CODECs doing strange things when configured for
	  multichannel recording, but I have also found successfully working
	  examples.</li>

	<li>Signal tracer was improved to look for cases where several
	  DACs/ADCs in CODEC can work with the same audio signal.  If such a
	  case is found, the driver registers additional playback/record stream
	  (channel) for the pcm device.  Having more than one stream allows
	  to avoid vchans use and so avoid extra conversion to vchan's
	  pre-configured sample rate and format.  Not many CODECs allow
	  this, especially on playback, but some do.</li>

	<li>New controller streams reservation mechanism was implemented.
	  That allows to have more pcm devices than streams supported by
	  the controller (usually 4 in each direction).  Now it limits only
	  number of simultaneously transferred audio streams, that is
	  rarely reachable and properly reported if happens.</li>

	<li>Codec pins and GPIO signals configuration was exported via
	  set of writable sysctls.  Another sysctl dev.hdaa.X.reconfig
	  allows to trigger driver reconfiguration in run-time.  The only
	  requirement is that all pcm devices should be closed at the
	  moment, as they will be destroyed and recreated.  This should
	  significantly simplify process of fixing CODEC configuration.  It
	  should be possible now even to write GUI to do it with few mouse
	  clicks.</li>

	<li>Driver now decodes pins location and connector type names.  In
	  some cases it gives a hint to the user where the connectors of
	  the pcm device are located on the system case.  The number of
	  channels supported by pcm device, reported now (if it is not 2),
	  should also make finding them easier.</li>
      </ul>

      <p>The code is in testing now and should be soon committed to the
	HEAD branch.</p>

      <p>Project sponsored by iXsystems, Inc.</p>
    </body>

    <help>
      <task>Closer inspection of HDMI/DisplayPort audio is
	planned.</task>

      <task>A number of hardware, mostly laptops, need workarounds to work
	properly.  Some statistics should be collected to implement some of
	them avoiding excessive code bloat.</task>
    </help>
  </project>

  <project cat='kern'>
    <title>SCSI Direct Access Driver (da) Improvements</title>

    <contact>
      <person>
	<name>
	  <given>Alexander</given>
	  <common>Motin</common>
	</name>
	<email>mav@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>BIO_DELETE support (aka TRIM) was added to the CAM SCSI Direct
	Access device driver (da).</p>

      <p>Depending on device capabilities different methods are used to
	implement it.  Currently used method can be read/set via
	kern.cam.da.X.delete_method sysctls.  Possible values are:</p>

      <ul>
	<li>NONE - no provisioning support reported by the device;</li>

	<li>DISABLE - provisioning support was disabled because of
	  errors;</li>

	<li>ZERO - use WRITE SAME (10) command to write zeroes;</li>

	<li>WS10 - use WRITE SAME (10) command with UNMAP bit set;</li>

	<li>WS16 - use WRITE SAME (16) command with UNMAP bit set;</li>

	<li>UNMAP - use UNMAP command (equivalent of the ATA DSM TRIM
	  command).</li>
      </ul>

      <p>The last two methods (UNMAP and WS16) are defined by SBC
	specification and the UNMAP method is the most advanced one.  The
	rest of the methods I have found supported in Linux, and as they
	were trivial to implement, then why not? I hope they will be useful
	in some cases.</p>

      <p>As side product of fetching logical block provisioning support
	flag, da driver also got support for reporting device physical
	sector size (aka Advanced Format) via stripesize/stripeoffset GEOM
	fields.  Some quirks were added for known 4K sector disks not
	reporting it properly.</p>

      <p>The code was committed to the HEAD branch and is going to be merged
	to 8/9-STABLE after some time.</p>

      <p>Project sponsored by iXsystems, Inc.</p>
    </body>

    <help>
      <task>To implement more effective selection of the best delete
	method some more parameters need to be obtained from the device.
	Unluckily none of devices I have report them.</task>
    </help>
  </project>

  <project cat='bin'>
    <title>Replacing the Regular Expression Code</title>

    <contact>
      <person>
	<name>
	  <given>G&aacute;bor</given>
	  <common>K&ouml;vesd&aacute;n</common>
	</name>
	<email>gabor@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://svnweb.FreeBSD.org/base/user/gabor/tre-integration/">
	Project repo</url>

      <url href="http://laurikari.net/tre/">TRE homepage</url>

      <url href="http://www.tdk.aut.bme.hu/Files/TDK2011/POSIX-regularis-kifejezesek1.pdf">
	A paper on the topic</url>
    </links>

    <body>
      <p>The current regular expression code in libc has to be replaced
	because it is old, unmaintained and does not support wide
	characters.  As it has been elaborated, TRE is the most suitable
	replacement outside that has an acceptable license.  However, the
	development of BSD grep also brought some relevant observations.  In
	short, there are some possibilities to optimize pattern matching
	but it is not possible with the POSIX API, because:</p>

      <ul>
	<li>It uses NUL-terminated strings that requires processing each
	  character and makes longer jumps impossible.</li>

	<li>It matches for one pattern at a time.  If more patterns are
	  searched, there are more efficient ways for pattern matching but
	  we have to know all of them and process them together.</li>
      </ul>

      <p>This project intends to implement these shortcut and provide
	efficient pattern matching for all programs that use regex
	matching.  It will also help avoiding the custom tricks that are
	hardcoded into some programs, like GNU grep, to work around the
	limiting POSIX API.  Besides, GNU grep has some extensions over the
	POSIX regular expression, which are necessary if we want to get rid
	of GNU code in the end.</p>
    </body>

    <help>
      <task>Implement multi-pattern heuristic regex matching.</task>

      <task>Implement GNU-specific regex extensions.</task>

      <task>Adapt BSD grep to use the multi-pattern interface.</task>

      <task>Test standard-compliance and correct behavior.</task>
    </help>
  </project>

  <project cat='docs'>
    <title>The &os; German Documentation Project</title>

    <contact>
      <person>
	<name>
	  <given>Benedict</given>
	  <common>Reuschling</common>
	</name>
	<email>bcr@FreeBSD.org</email>
      </person>

      <person>
	<name>
	  <given>Johann</given>
	  <common>Kois</common>
	</name>
	<email>jkois@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="https://doc.bsdgroup.de/">Homepage of the &os; German
	Documentation Project</url>

      <url href="http://www.FreeBSD.org/doc/de_DE.ISO8859-1/books/handbook/bsdinstall.html">
	The German translation of the bsdinstall handbook chapter</url>
    </links>

    <body>
      <p>The German Documentation Project is happy to report that two big
	chapters have been translated in the past quarter.  The first update
	is in the firewall chapter and covering the complete IPFW section.
	It was contributed by Christopher J. Ruwe.  There were style and
	language fixes to be done, but the biggest amount of work, the
	actual translation, was done by him.  We thank Christopher very
	much.</p>

      <p>The other chapter that was translated is the new bsdinstall
	chapter.  Benedict Reuschling did the work on this chapter.  He tried
	to keep the same titles for sections that are mostly describing the
	same things as in the sysinstall chapter (at least where this was
	possible).</p>

      <p>German speaking users are encouraged to read both chapters and
	report typos or grammar errors back to us so we can fix them.</p>

      <p>The German website is being updated on a regular basis.</p>
    </body>

    <help>
      <task>Catch up with the latest changes made to the
	documentation.</task>

      <task>Translate more www pages into German.</task>

      <task>Find bugs in the German documentation and fix them.</task>
    </help>
  </project>

  <project cat='ports'>
    <title>&os;/GNOME</title>

    <contact>
      <person>
	<name>
	  <given>GNOME &os; mailing list</given>
	</name>
	<email>freebsd-gnome@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.FreeBSD.org/gnome" />

      <url href="http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi/" />
    </links>

    <body>
      <p>It has been a while since we did a status report.</p>

      <p>This year we started work on GNOME 3.0.  Due to time constrains
	and lack of man power, this version did not make it into the ports.
	Currently we have 3.2 in our development repo.  See the development
	FAQ on our website for details.  The MC-UPDATING file contains
	upgrade instructions.</p>

      <p>Currently the GNOME team is understaffed, help is welcome!</p>
    </body>

    <help>
      <task>Update the &os; gnome website with GNOME 3.x information, and
	still supply the 2.32.x info.</task>
    </help>
  </project>

  <project cat='ports'>
    <title>Up to Date X.Org Server</title>

    <contact>
      <person>
	<name>
	  <given>X11 &os; mailing list</given>
	</name>
	<email>freebsd-x11@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://wiki.FreeBSD.org/Xorg" />
    </links>

    <body>
      <p>The X11 team has started work on the next major update for the
	X.Org ports.  You might have noticed libraries and proto ports being
	updated that belong to the X.Org stack.  Currently in our development
	repository we have the latest versions of many ports including mesa
	and xf86-video-intel.</p>

      <p>We support versions 1.7.7 and 1.10.4 of the X.Org tree for users
	with the appropriate hardware and patches.</p>

      <p>We need more testers for both the standard version from
	xorg-devel and the WITH_NEW_XORG version.  We also need testers for
	updated input/video drivers, especially for the less mainstream
	ones.</p>

      <p>In order to test check out our svn repository from <a
	  href="http://trillian.chruetertee.ch/ports/browser/branches/xorg-dev">
	  http://trillian.chruetertee.ch/ports/browser/branches/xorg-dev</a> and
	the merge script from <a
	  href="http://people.FreeBSD.org/~miwi/xorg/xorgmerge">
	  http://people.FreeBSD.org/~miwi/xorg/xorgmerge</a>.  See the wiki for
	more details.</p>
    </body>

    <help>
      <task>Investigate xorg-server 1.12 which brings xinput 2.2.</task>

      <task>Merge development repository into the main repository, after
	more testing.</task>
    </help>
  </project>

  <project cat='proj'>
    <title>pfSense</title>

    <contact>
      <person>
	<name>
	  <given>Scott</given>
	  <common>Ullrich</common>
	</name>
	<email>sullrich@gmail.com</email>
      </person>

      <person>
	<name>
	  <given>Chris</given>
	  <common>Buechler</common>
	</name>
	<email>cbuechler@gmail.com</email>
      </person>

      <person>
	<name>
	  <given>Ermal</given>
	  <common>Luçi</common>
	</name>
	<email>ermal.luci@gmail.com</email>
      </person>
    </contact>

    <links>
      <url href="http://www.pfsense.org/">pfSense homepage</url>
    </links>

    <body>
      <p>pfSense is a free and open source customized distribution of
	&os; tailored for use as a firewall and router.</p>

      <p>2.0.1 was just released which corrected a number of issues
	<a href="http://blog.pfsense.org/?p=633">
	  http://blog.pfsense.org/?p=633</a>.</p>
    </body>

    <help>
      <task>6 month release cycle.</task>

      <task>Moving builds to &os; 9.</task>

      <task>Full IPV6 support.</task>

      <task>PBI Package binaries.</task>

      <task>Unbound integration.</task>

      <task>Multi-instance Captive Portal.</task>

      <task>Replacing Prototype with jQuery.</task>
    </help>
  </project>

  <project cat='team'>
    <title>Release Engineering Team Status Report</title>

    <contact>
      <person>
	<name>
	  <given>Release Engineering Team</given>
	</name>
	<email>re@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.FreeBSD.org/releng/" />
    </links>

    <body>
      <p>The Release Engineering Team was pleased to announce the release
	of &os;-9.0 on January 12th, 2012.  To acknowledge his incredible
	contributions to the world of computing and in particular the &os;
	Project's corner of that world &os;-9.0 was dedicated to Dennis
	Ritchie.  May he rest in peace.  The Release Engineering Team also
	wishes to thank the &os; Developers and Community for all the work
	they put into the release.</p>

      <p>With the &os;-9.0 release cycle completed our focus shifts to
	preparing for the &os;-8.3 release.  A schedule has not been set but
	we expect to be shooting for release some time in March 2012.</p>
    </body>
  </project>

  <project cat='proj'>
    <title>Auditdistd Project</title>

    <contact>
      <person>
	<name>
	  <given>Pawel Jakub</given>
	  <common>Dawidek</common>
	</name>
	<email>pjd@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>Current weakness of &os;'s Security Event Audit facility is that
	audit records are stored locally and can be modified or removed by
	an attacker after a system compromise.</p>

      <p>The auditdistd will allow to reliably and securely distribute
	audit trail files over TCP/IP network to remote system.  In case of
	system compromise it will enable administrators to analyze audit
	records in trusted environment.</p>

      <p>This project is sponsored by the &os; Foundation and should be
	completed by the end of February 2012.</p>
    </body>
  </project>

  <project cat='kern'>
    <title>&os; No-IPv4 (&quot;IPv6-Only&quot;) Support</title>

    <contact>
      <person>
	<name>
	  <given>Bjoern A.</given>
	  <common>Zeeb</common>
	</name>
	<email>bz@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.FreeBSD.org/ipv6/ipv6only.html">FreeBSD
	No-IPv4 Support</url>
    </links>

    <body>
      <p>The No-IPv4 (fka. &quot;IPv6-Only&quot;) project initially
	prototyped in p4 and merged into mainstream &os; with support from
	the &os; Foundation and iXsystems earlier in 2011 for World IPv6
	Day continued as a free time project.  Thanks to the help of an
	anonymous source, dedicated i386 and amd64 build machines and a
	distribution node were setup to allow continuous building of
	snapshots and we hope to extend the support for the snapshots in
	the future providing more services.</p>

      <p>During the 9.0 release cycle a BETA and an RC snapshot were
	built and released. &os; 9.0-RELEASE will be the first official
	release supporting a kernel to compile out IPv4 support.  We will
	provide (and given 9.0 is out at time of writing do provide) a
	no-IPv4 snapshot accompanying the official release and hope for
	your feedback.</p>

      <p>I would like to thank Hiroki Sato/allbsd.org for providing a mirror
	in Japan for the Asian community in addition to mine in Europe.</p>
    </body>

    <help>
      <task>Commit/Submit upstream a few user space fixes.</task>

      <task>More user space cleanup and testing.</task>

      <task>Get rid of <tt>gethostby*()</tt> calls.</task>
    </help>
  </project>

  <project cat='arch'>
    <title>&os;/powerpc on AppliedMicro APM86290</title>

    <contact>
      <person>
	<name>
	  <given>Grzegorz</given>
	  <common>Bernacki</common>
	</name>
	<email>gjb@semihalf.com</email>
      </person>

      <person>
	<name>
	  <given>Rafal</given>
	  <common>Jaworowski</common>
	</name>
	<email>raj@semihalf.com</email>
      </person>
    </contact>

    <body>
      <p>The APM86290 system-on-chip device is a member of AppliedMicro's
	PACKETpro family of embedded processors.</p>

      <p>The chip includes two Power Architecture PPC465 processor cores,
	which are compliant with Book-E specification of the architecture,
	and a number of integrated peripherals.</p>

      <p>This work is extending current Book-E support in &os; towards
	PPC4xx processors variation along with device drivers for
	integrated peripherals.</p>

      <p>The following drivers have been created since the last
	report:</p>

      <ul>
	<li>Ethernet controller driver</li>

	<li>Classifier driver</li>

	<li>Finished Queue Manager/Traffic Manager</li>

	<li>Improved performance and stability</li>
      </ul>

      <p>Next steps:</p>

      <ul>
	<li>L2 cache support</li>

	<li>Merge APM86290 support to -CURRENT</li>
      </ul>
    </body>
  </project>

  <project cat='arch'>
    <title>&os;/powerpc on Freescale QorIQ DPAA</title>

    <contact>
      <person>
	<name>
	  <given>Michal</given>
	  <common>Dubiel</common>
	</name>
	<email>md@semihalf.com</email>
      </person>

      <person>
	<name>
	  <given>Rafal</given>
	  <common>Jaworowski</common>
	</name>
	<email>raj@semihalf.com</email>
      </person>

      <person>
	<name>
	  <given>Piotr</given>
	  <common>Ziecik</common>
	</name>
	<email>kosmo@semihalf.com</email>
      </person>
    </contact>

    <links>
      <url href="http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P2040">
	P2041 product page</url>

      <url href="http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P3041">
	P3041 product page</url>

      <url href="http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P5020">
	P5020 product page</url>
    </links>

    <body>
      <p>The QorIQ Data Path Acceleration Architecture (DPAA) from
	Freescale is a comprehensive architecture, which integrates all
	aspects of packet processing in the SoC, addressing issues and
	requirements resulting from the nature of QorIQ multicore SoCs.  It
	includes:</p>

      <ul>
	<li>Cores</li>

	<li>Network and packet I/O</li>

	<li>Hardware offload accelerators</li>

	<li>The infrastructure required to facilitate the flow of packets
	  between the above</li>
      </ul>

      <p>The DPAA also addresses various performance related
	requirements, especially those created by the high speed network
	I/O found on multicore SoCs such as P2041, P3041, P5020, etc.  This
	work is bringing up &os; on these system-on-chip devices along with
	device drivers for integrated peripherals.</p>

      <p>Current &os; QorIQ DPAA support includes:</p>

      <ul>
	<li>QorIQ P2041 and P3041 devices</li>

	<li>E500mc core complex</li>

	<li>Adaptation of toolchain for the new core</li>

	<li>Booting via U-Boot bootloader</li>

	<li>CoreNet interconnect fabric</li>

	<li>L1, L2, L3 cache</li>

	<li>Serial console (UART)</li>

	<li>Interrupt controller</li>

	<li>DPAA infrastructure (BMAN, FMAN, QMAN)</li>

	<li>Ethernet (basic network functionality using Independent Mode
	  of DPAA infrastructure)</li>

	<li>EHCI controller</li>

	<li>PCI Express controller (host mode)</li>

	<li>SMP support (up to quad-core)</li>

	<li>I2C</li>
      </ul>

      <p>Next steps:</p>

      <ul>
	<li>QorIQ P5020 (32-bit mode) support</li>

	<li>Ethernet (full network functionality using Regular Mode of
	  DPAA infrastructure)</li>

	<li>Enhanced SDHC</li>
      </ul>
    </body>
  </project>

  <project cat='arch'>
    <title>&os;/arm on Marvell Armada XP</title>

    <contact>
      <person>
	<name>
	  <given>Grzegorz</given>
	  <common>Bernacki</common>
	</name>
	<email>gjb@semihalf.com</email>
      </person>

      <person>
	<name>
	  <given>Rafal</given>
	  <common>Jaworowski</common>
	</name>
	<email>raj@semihalf.com</email>
      </person>
    </contact>

    <links>
      <url href="http://svnweb.FreeBSD.org/base/projects/armv6/">ARMv6
	branch</url>
    </links>

    <body>
      <p>Marvell Armada XP is a complete system-on-chip solution based on
	Sheeva embedded CPU.  These devices integrate up to four ARMv6/v7
	compliant Sheeva CPU cores with shared L2 cache.</p>

      <p>This work is extending the &os;/arm infrastructure towards support
	for recent ARM architecture variations along with a basic set of
	device drivers for integrated peripherals.</p>

      <p>The following code has been implemented since the last status
	report:</p>

      <ul>
	<li>SMP support</li>

	<ul>
	  <li>Implemented TLB broadcast and RFO</li>

	  <li>Tested 2 and 4 cores setup in WT cache mode</li>
	</ul>

	<li>SATA driver integrated and tested</li>

	<li>CESA driver integrated and tested</li>
      </ul>

      <p>Next steps:</p>

      <ul>
	<li>L2 cache support</li>

	<li>Full support for WB/WBA cache</li>
      </ul>
    </body>
  </project>

  <project cat='team'>
    <title>The &os; Foundation Status Report</title>

    <contact>
      <person>
	<name>
	  <given>Deb</given>
	  <common>Goodkin</common>
	</name>
	<email>deb@FreeBSDFoundation.org</email>
      </person>
    </contact>

    <links>
      <url href="www.FreeBSDFoundation.org" />
    </links>

    <body>
      <p>The most exciting news to report is that we raised $426,000
	through our fundraising efforts.  We were overwhelmed by the
	generosity of the &os; community.  We would like to thank everyone
	who made a contribution to &os; by either making a financial
	donation to the foundation or volunteering on the Project.</p>

      <p>We published our <a
	  href="http://www.FreeBSDFoundation.org/press/2011Dec-newsletter.shtml">
	  semi-annual newsletter</a> in December.  If you have not
	already done so, please take a moment to read this publication
	to find out how we supported the &os; Project and community
	during the second half of 2011.  There are also two great
	testimonials in the newsletter from TaxiMagic and the Apache
	Software Foundation.</p>

      <p>The Foundation sponsored EuroBSDCon 2011 which was held in The
	Netherlands, October 6-9.  And, we sponsored six developers to
	attend the conference.  We sponsored the Bay Area Vendor Summit in
	November.  We were represented at LISA '11, Dec 7-8 in Boston
	MA.</p>

      <p>We are a proud sponsor of AsiaBSDCon 2012, which will be held in
	Tokyo, Japan, March 22-25.</p>

      <p>The Foundation funded project Feed-Forward Clock Synchronization
	Algorithms Project by the University of Melbourne completed.  We
	approved two new projects for 2012, they are analyzing the
	performance of &os;'s IPv6 stack by Bjoern Zeeb, and implementing
	auditdistd daemon by Pawel Jakub Dawidek</p>

      <p>We purchased more servers and other hardware for the &os;
	co-location centers at Sentex, NYI, and ISC.</p>

      <p>The work above, as well as many other tasks which we do for the
	&os; Project, could not be done without donations.  Please help us by
	making a donation or asking your company to make a donation.  We
	would be happy to send marketing literature to you or your company.
	Find out how to make a donation at <a
	  href="http://www.FreeBSDFoundation.org/donate/">our donate
	  page</a>.</p>

      <p>Find out more up-to-date Foundation news by reading our <a
	  href="http://FreeBSDFoundation.blogspot.com/">blog</a> and
	<a href="http://www.facebook.com/FreeBSDFoundation">Facebook</a>
	page.</p>
    </body>
  </project>

  <project cat='team'>
    <title>&os; Ports Management Team Status Report</title>

    <contact>
      <person>
	<name>
	  <given>Thomas</given>
	  <common>Abthorpe</common>
	</name>
	<email>portmgr-secretary@FreeBSD.org</email>
      </person>

      <person>
	<name>
	  <given>Port</given>
	  <common>Management Team</common>
	</name>
	<email>portmgr@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.FreeBSD.org/ports/" />

      <url href="http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/" />

      <url href="http://portsmon.FreeBSD.org/index.html" />

      <url href="http://www.FreeBSD.org/portmgr/index.html" />

      <url href="http://blogs.FreeBSDish.org/portmgr/" />

      <url href="http://www.twitter.com/freebsd_portmgr/" />

      <url href="http://www.facebook.com/group.php?gid=135441496471197" />
    </links>

    <body>
      <p>The ports tree finally surpassed 23,000 ports.  The PR count
	still remains at about 1100.</p>

      <p>In Q4 we added 4 new committers, took in 4 commit bit for safe
	keeping, and had one committer return to ports work.</p>

      <p>The Ports Management team have been running -exp runs on an
	ongoing basis, verifying how base system updates may affect the
	ports tree, as well as providing QA runs for major ports updates.
	Of note, -exp runs were done for:</p>

      <ul>
	<li>KDE4 and cmake updates</li>

	<li>Multiple runs to test and fix breakages induced by the bump
	in digits for &os; 10</li>

	<li>Verify the removal of X11BASE from ports</li>

	<li>Test ports after import of flex and m4 into src base</li>

	<li>Optimizations to bsd.ports.mk</li>

	<li>Test xcb update and split into multiple ports</li>

	<li>Estimate number of ports utilizing old interface ioctls</li>

	<li>Ongoing validation of infrastructure with pkgng</li>

	<li>testing ports with clang as default compiler</li>
      </ul>

      <p>pkgng now has real safe binary upgrade, as well as real
	integrity checking, work has been started to have the ports tree
	be able to bootstrap pkgng.  More info on the <a
	  href="http://lists.FreeBSD.org/pipermail/freebsd-ports/2011-November/071631.html">
	  CFT email.</a>.</p>

      <p>The pointyhat-west build machine continues toward production
	use, code updates have made it more versatile such as swapping out
	information in make.conf for build slaves, assist in testing of
	pkgng -exp runs and to properly build linux_base ports.</p>

      <p>It has been decided that the ports tree will be migrated from
	CVS to Subversion, beat@ will be in charge of the project.  More
	information on the <a
	href="http://wiki.FreeBSD.org/PortsSVN">wiki</a>.</p>

      <p>A moderated mailing list has been created for ports related
	announcements, <a
	  href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports-announce">
	  http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports-announce</a>,
	it is intended, but not limited, to be a means of communicating
	portmgr@ announcements, Calls for Testing, plus other relevant
	information to be used by our committers and ports maintainer
	community.</p>
    </body>

    <help>
      <task>Looking for help getting <a
	  href="http://wiki.FreeBSD.org/PortsAndClang">ports to build
	  with clang</a>.</task>

      <task>Looking for help fixing <a
	  href="http://wiki.FreeBSD.org/PortsBrokenOnCurrent">ports broken
	  on CURRENT</a>.  (List needs updating, too)</task>

      <task>Looking for help with <a
	  href="http://wiki.FreeBSD.org/PortsBrokenOnTier2Architectures">
	  Tier-2 architectures</a>.</task>

      <task><a
	  href="http://wiki.FreeBSD.org/PortsBrokenBySrcChanges">ports
	  broken by src changes</a>.</task>

      <task><a
	  href="http://wiki.FreeBSD.org/PortsFailingOnPointyhat">ports
	  failing on pointyhat</a>.</task>

      <task><a
	  href="http://wiki.FreeBSD.org/PortsFailingOnPointyhatWest">ports
	  failing on pointyhat-west</a>.</task>

      <task><a
	  href="http://wiki.FreeBSD.org/Trybroken">ports that are marked
	  as BROKEN</a>.</task>

      <task><a
	  href="http://wiki.FreeBSD.org/WhenDidThatPortBreak">When did
	  that port break</a>.</task>

      <task>Most ports PRs are assigned, we now need to focus on testing,
	committing and closing.</task>
    </help>
  </project>

  <project cat='ports'>
    <title>Multimedia &mdash; Watching/Recording Digital TV</title>

    <contact>
      <person>
	<name>
	  <given>Hans Petter</given>
	  <common>Selasky</common>
	</name>
	<email>hselasky@FreeBSD.org</email>
      </person>

      <person>
	<name>
	  <given>Jason</given>
	  <common>Harmening</common>
	</name>
	<email>jason.harmening@gmail.com</email>
      </person>

      <person>
	<name>
	  <given>Juergen</given>
	  <common>Lock</common>
	</name>
	<email>nox@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://wiki.FreeBSD.org/WebcamCompat">Tested DVB and
	other hardware</url>

      <url href="http://wiki.FreeBSD.org/HTPC" />

      <url href="http://wiki.FreeBSD.org/VDR" />
    </links>

    <body>
      <p>Progress has been made when watching/recording live digital TV
	using &os;:</p>

      <ul>
	<li><a href="http://freshports.org/multimedia/webcamd">
	    multimedia/webcamd</a> is continuously adding support for
	  more and more USB tuners using the Linux V4L/DVB drivers
	  (also including remotes via webcamd and <a
	    href="http://freshports.org/comms/lirc">comms/lirc</a>.)</li>

	<li><a href="http://freshports.org/multimedia/cx88">
	    multimedia/cx88</a> recently added Linux DVB API support
	  for CX88-based PCI(-e) DVB-T tuners so "common" apps can now
	  also be used with that hardware.</li>

	<li><a href="http://freshports.org/multimedia/xbmc-pvr">
	    multimedia/xbmc-pvr</a> was committed recently and the <a
	    href="http://wiki.FreeBSD.org/VDR">multimedia/vdr</a>
	  ports are working too for watching/recording live digital TV, and
	  also other apps like kaffeine, or mplayer, or vlc.</li>
      </ul>
    </body>

    <help>
      <task>Continue updating the VDR ports to the latest versions and
	fix remaining bugs.</task>

      <task>Update <a href="http://freshports.org/multimedia/libxine">
	  multimedia/libxine</a> to 1.2.0 that recently was released
	(which VDR uses.)</task>

      <task>Test more hardware?</task>
    </help>
  </project>

  <project cat='arch'>
    <title>Improving Support for New Features in the Intel SandyBridge CPUs</title>

    <contact>
      <person>
	<name>
	  <given>Konstantin</given>
	  <common>Belousov</common>
	</name>
	<email>kib@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>Support for new features in the Intel SandyBridge CPUs is
	progressing.</p>

      <p>The patch to query and allow extended FPU states was committed,
	which enabled the YMM registers and AVX instruction set on the
	capable processors.  Todo items include get wider testing of the
	change before planned merge to stable/9 in a month, and start
	using XSAVEOPT instruction to optimize context switch times.</p>

      <p>Patch to enable and use per-process TLB was developed.  Latest
	version is available at <a
	  href="http://people.freebsd.org/~kib/misc/pcid.2.patch">
	  http://people.freebsd.org/~kib/misc/pcid.2.patch</a>.  The facility,
	referred in the documentation as PCID, allows to avoid TLB flush
	on context switches by applying PID tag to each non-global TLB
	entry.  On SandyBridge, measurements did not prove any difference
	between context switch latencies on patched and stock kernels.</p>

      <p>Forthcoming IvyBridge CPUs promised to provide optimizations in
	the form of INVPCID instructions that allow to optimize TLB
	shootdown handlers. The patch above uses the instruction on the
	capable CPU.  Todo items are to get access to IvyBridge and do the
	benchmarks.</p>

      <p>Future work might provide SEP support, use hardware random
	generator from IvyBridge for random(4), considering using faster
	instructions to access %fs and %gs bases, and use improved AES-NI
	instruction set for aesni(4).</p>
    </body>
  </project>

  <project cat='kern'>
    <title>CAM Target Layer (CTL)</title>

    <contact>
      <person>
	<name>
	  <given>Ken</given>
	  <common>Merry</common>
	</name>
	<email>ken@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://lists.FreeBSD.org/pipermail/freebsd-current/2012-January/031007.html" />
    </links>

    <body>
      <p>The CAM Target Layer (CTL) is now in &os;/head.</p>

      <p>CTL is a disk and processor device emulation subsystem originally
	written for Copan Systems under Linux starting in 2003.  It
	has been shipping in Copan (now SGI) products since 2005.</p>

      <p>It was ported to &os; in 2008, and thanks to an agreement
	between SGI (who acquired Copan's assets in 2010) and Spectra
	Logic in 2010, CTL is available under a BSD-style license.  The
	intent behind the agreement was that Spectra would work to get
	CTL into the &os; tree.</p>

      <p>It will likely be merged into the stable/9 tree in
	mid-February.</p>

      <p>Some CTL features:</p>

      <ul>
	<li>Disk and processor device emulation</li>
	<li>Tagged queueing</li>
	<li>SCSI task attribute support (ordered, head of queue,
	  simple tags)</li>
	<li>SCSI implicit command ordering support.  (e.g. if a read
	  follows a mode select, the read will be blocked until the
	  mode select completes.)</li>
	<li>Full task management support (abort, LUN reset, target
	  reset, etc.)</li>
	<li>Support for multiple ports</li>
	<li>Support for multiple simultaneous initiators</li>
	<li>Support for multiple simultaneous backing stores</li>
	<li>Persistent reservation support</li>
	<li>Mode sense/select support</li>
	<li>Error injection support</li>
	<li>High Availability support (1)</li>
	<li>All I/O handled in-kernel, no userland context switch
	  overhead.</li>
      </ul>

      <p>(1) HA Support is just an API stub, and needs much more to be fully
	functional.</p>

      <p>For the basics on configuring and running CTL, see
	src/sys/cam/ctl/README.ctl.txt in the &os;/head source
	tree.</p>
    </body>
  </project>

  <project cat='kern'>
    <title>LSI Supported mps(4) SAS driver</title>

    <contact>
      <person>
	<name>
	  <given>Ken</given>
	  <common>Merry</common>
	</name>
	<email>ken@FreeBSD.org</email>
      </person>

      <person>
	<name>
	  <given>Kashyap</given>
	  <common>Desai</common>
	</name>
	<email>Kashyap.Desai@lsi.com</email>
      </person>
    </contact>

    <links>
      <url href="http://lists.FreeBSD.org/pipermail/freebsd-current/2012-January/031358.html" />
    </links>

    <body>
      <p>The LSI-supported version of the mps(4) driver, that supports
	their 6Gb SAS controllers and WarpDrive solid state drives, is
	available in &os;/head.</p>

      <p>In addition to WarpDrive support, the driver also has several
	other new features:</p>

      <ul>
	<li>Integrated RAID (IR) support</li>
	<li>Improved error recovery code</li>
	<li>Support for SCSI protection information (EEDP)</li>
	<li>Support for TLR (Transport Level Retries), needed for tape
	  drives</li>
	<li>ioctl interface compatible with LSI utilities</li>
      </ul>

      <p>Thanks to LSI for doing the work on this driver, and the
	testing.</p>

      <p>I plan to merge it into stable/9 and stable/8 in early
	February.</p>
    </body>
  </project>
</report>
