diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2013-07-2013-09.xml b/en_US.ISO8859-1/htdocs/news/status/report-2013-07-2013-09.xml index d52d39c8a9..5b7fb48f61 100644 --- a/en_US.ISO8859-1/htdocs/news/status/report-2013-07-2013-09.xml +++ b/en_US.ISO8859-1/htdocs/news/status/report-2013-07-2013-09.xml @@ -1,1646 +1,1647 @@ July-September 2013
Introduction

This report covers &os;-related projects between July and September 2013. This is the third of four reports planned for 2013.

Thanks to all the reporters for the excellent work! This report contains 30 entries and we hope you enjoy reading it.

The deadline for submissions covering between October and December 2013 is not yet decided.

team &os; Team Reports proj Projects kern Kernel arch Architectures bin Userland Programs ports Ports doc Documentation soc Google Summer of Code misc Miscellaneous AES-NI Improvements for GELI John-Mark Gurney jmg@FreeBSD.org

An enhancement to the AES-NI implementation for OpenCrypto has been committed that significantly improves AES-XTS and AES-CBC decryption performance. This gives geli(8) around a three times performance boost on gnop(8) using AES-XTS compared to the old code.

These improvements are available to users of the OpenCrypto framework and crypto(4).

 Static Code Analysis Ulrich Spoerlein uqs@FreeBSD.org Coverity Scan Clang Static Analyzer Scan for &os; Clang Static Analyzer Home Page

With our own (old and unstable) instance of Coverity Prevent gone, we have now fully transitioned to the Scan project run by Coverity (see links), which Open Source projects can use to learn about possible defects in their source code.

We also continue to run our code base through the Static Analyzer that is shipped with Clang/LLVM. It cannot track the state of the code over time, but has the benefit that everyone can use it without any special setup. See the home page at the links section for more information on the Clang Static Analyzer project in general, and head over to the &os; Clang Static Analyzer Scan page (see links) to see those possible defects (no signup required).

We are looking for a co-admin for both of these projects to increase the bus-factor and the chance of survival for these services. Fame and fortune await!

Maybe turn on email reports for new defects to the internal list of &os; developers. Find co-admin. Fix the defects reported by Coverity and Clang. GEOM Direct Dispatch and Fine-Grained CAM Locking Alexander Motin mav@FreeBSD.org Project SVN branch Project patches

Last year's high-performance storage vendors reported a performance bottleneck in the &os; block storage subsystem, limiting peak performance around 300-500K IOPS. While that is still more than enough for average systems, detailed investigation has shown a number of places that require radical improvement. Unmapped I/O support implemented early this year already improved I/O performance by about 30% and moved more accents toward GEOM and CAM subsystems scalability. Fixing these issues was the goal of this project.

The existing GEOM design assumed most I/O handling to be done by only two kernel threads (g_up() and g_down()). That simplified locking in some cases, but limited potential SMP scalability and created additional scheduler overhead. This project introduces the concept of direct I/O dispatch into GEOM for cases where it is known to be safe and efficient. That implies marking some GEOM consumers and providers with one or two new flags, declaring situations when a direct function call can be used instead of normal request queuing. That allows avoiding any context switches inside GEOM for the most widely used topologies, simultaneously processing multiple I/Os from multiple calling threads.

Having GEOM passing through multiple concurrent calls down to the underlying layers exposed major lock congestion in CAM. In the existing CAM design all devices connected to the same ATA/SCSI controller are sharing a single lock, which can be quite busy due to multiple controller hardware accesses and/or code logic. Experiments have shown that applying only the above GEOM direct dispatch changes burns up to 60% of system CPU time or even more in attempts to obtain these locks by multiple callers, killing any benefits of GEOM direct dispatch. To overcome that, new fine-grained CAM locking design was implemented. It implies splitting big per-SIM locks into several smaller ones: per-LUN locks, per-bus locks, queue locks, etc. After these changes, the remaining per-SIM lock protects only the controller driver internals, reducing lock congestion down to an acceptable level and keeping keep compatibility with existing drivers.

Together, GEOM and CAM changes double the peak I/O rate, reaching up to 1,000,000 IOPS on contemporary hardware.

The changes were tested by a number of people and will be committed into &os; head and merged to stable/10 after the end of the &os; 10.0 release cycle.

The project is sponsored by iXsystems, Inc.

More reviews, more stability and performance tests. VMware VMXNET3 Driver Bryan Venteicher bryanv@freebsd.org

A port of the OpenBSD vmx(4) ethernet driver has been committed. The driver can be used in place of the VMware Tools vmxnet3 driver, which currently does not support 10.0-RELEASE (or anything past 9.0-RELEASE).

Performance improvements, multiqueue support. Merge to stable/9. VirtIO Network Multiqueue Bryan Venteicher bryanv@freebsd.org

The VirtIO network driver, vtnet(4), recently gained support for multiple queues, along with a significant cleanup and support for a few additional features.

 &os; Python Ports &os; Python Team python@FreeBSD.org The &os; Python Team Page IRC channel

We are currently working on cleaning up the lang/python* ports to improve the compatibility with the original upstream build behaviour and to lower the need for &os;-specific build patches. A first step was made in September by reducing the flags injected into the different Python interpreter versions.

The first tasks for supporting the installation of packages for different Python ports have been done. A new metaport structure has replaced the original Python port behaviour and will be enhanced over the next months to enable improved installation support of packages for different Python versions at the same time.

The Python ports framework was enhanced by automated packaging list creation and replacement macros, which improve the compatibility with multiple Python versions and reduce the packaging list sizes.

PyPy was heavily enhanced over the last couple of months. Major updates of the port solved integration issues and a new pypy-devel port for snapshots and previews was added. Since the PyPy 3 release, there is a new pypy3-devel port available to provide not only compatibility for Python 2.x specific scripts, but also for those using the 3.x language specification.

IronPython found its way into the &os; ports tree, which provides an implementation of the Python language based on .NET and Mono.

Develop a high-level and lightweight Python Ports Policy. Chase the unification of Distribute (devel/py-distribute) and Setuptools (devel/py-setuptools*). Add support for granular dependencies (for example >=1.0 or < 2.0). Look at what adding pip (Python Package Index) support looks like. More tasks can be found on the Team's wiki page (see links). The <tt>entities</tt> Documentation Branch René Ladan rene@FreeBSD.org

The entities project branch has been succesfully merged into the main documentation branch per revision 42226 of the doc repository (see link). The purpose of this branch was to remove the duplicated definitions of authors in both authors.ent and developers.ent. The latter file has been removed after migrating its contents to the former file. While most changes are not visible to end users, the Committers Guide was changed to accomodate for changes related to adding a new committer. Translators were also informed of the update. The largest hurdle mentioned in the last report, processing the <email> element, was solved with the help of Gábor Kövesdán.

 &os; Release Engineering Team &os; Release Engineering Team re@FreeBSD.org &os; 9.2-RELEASE schedule &os; 10.0-RELEASE schedule &os; Virtual Machine Images &os; Development Snapshots

The &os; Release Engineering Team has completed the 9.2-RELEASE process. The release cycle changed with a last-minute addition of 9.2-RC4. The 9.2-RELEASE was announced September 30, four weeks behind the original schedule.

The &os; 10.0-RELEASE cycle has started, and testing is strongly encouraged. For testing purposes, both installation images and virtual machine images exist on the &os; Project FTP servers.

Test 10.0-CURRENT and report problems. Download Manager Service for the Ports Collection Ambarisha Bhatlapenumarthi ambarisha@freebsd.org Xin Li delphij@freebsd.org Project wiki page More information on DMS

This is a Google Summer of Code 2013 project that aims to replace the fetch(1)-based method for getting distribution files, such as source tarballs, for the third-party applications (ports) with an intelligent Download Manager Service (see links for more information).

All the modules highlighted in the project wiki have been completed (see links). Specifically:

The implementation (especially job migration and dumping status) has not been tested thoroughly. Test the code, write more unit and regression tests. &os; Ada Ports John Marino marino@FreeBSD.org

A few years ago, Ada-based ports almost completely disappeared from the Ports Collection. This was not surprising as FSF GNAT, the only open-source Ada compiler, ceased to build correctly on any BSD flavor and previously built bootstrap compilers would not run on modern &os;, and certainly not on amd64. The first step, see the link for details, was to patch GCC in order to fix GNAT not only on &os;, but DragonFly, NetBSD, and OpenBSD as well. New bootstraps for both i386 and amd64 platforms were produced during this effort. Ada compilers on &os; now pass 100% of the ACATS and GCC testsuites.

With the first new Ada compiler port was introduced, the GCC 4.6-based lang/gnat-aux, the GNAT Programming Studio (multilanguage integrated development environment), XML/Ada, and GTkAda were among the first Ada ports resurrected.

With the latest compiler, lang/gcc-aux based on GCC 4.7, a cohesive Ada framework was created with the new USES= capability. Currently around 20 ports are part of this framework including Florist, ASIS, GPRbuild, QtAda, AdaControl, AdaBrowse, PolyOrb, and AWS (Ada Web Server).

The GNAT AUX compiler is also still in use to serve as a basis for the GNATDroid ports which are &os;-to-Android Ada+C cross-compilers. However, these will soon be integrated in the Ada Framework.

At this point, it looks like that &os; (shared with DragonFly via DPorts) has taken the crown from Debian as the recognized best Ada development platform. The &os; versions of the software are more recent and the Ports Collection has ports not available on Debian, such as LibSparkCrypto, Matreshka library, and the Ahven unit tester.

Future work potentially includes converting GCC AUX to GCC 4.8 to acquire better Ada 2012 support, importing Spark 2014 into ports when it arrives and to continue to add new Ada ports to the framework.

 &os; on Cubieboard2 Ganbold Tsagaankhuu ganbold@FreeBSD.org

Initial support of Allwinner A20 SoC is committed to head. A20 SoC on Cubieboard2 is pin-to-pin compatible with A10 in Cubieboard1 and &os; supports the following peripherals:

Get the EMAC Ethernet driver working. Need more help from network driver experts. Add more drivers. &os;/EC2 Colin Percival cperciva@freebsd.org &os;/EC2 Status Page AWS Marketplace Listing

&os; images are available for use in EC2 for 8.3-RELEASE, 8.4-RELEASE, 9.0-RELEASE, 9.1-RELEASE, and 9.2-RELEASE. In 9.2-RELEASE, &os; runs in EC2 using an unpatched source tree, but it needs the XENHVM kernel configuration.

Starting from &os; 10.0-ALPHA3, the GENERIC kernel configuration now contains all the XENHVM bits needed to allow &os; to run in EC2 natively. Consequently, &os; 10.0 will be the first release for which &os;/EC2 is purely "bits off the ISO". This also means that starting with 10.0 it will be possible to use freebsd-update(8) for all base system updates — in earlier releases it was necessary to recompile the XENHVM kernel manually.

Due to &os;'s use of HVM virtualization, running on "old" EC2 instance types (m1, m2, c1, t1) requires that &os; pretends to be Windows, which unfortunately results in paying the higher "windows" EC2 instance prices. On "new" EC2 instances (cc1, cc2, cg1, cr1, hi1, hs1, and m3) &os; can run as a "unix" image at the lower rate.

Test &os; 10.0-ALPHAs/BETAs/RCs as they become available. Plenty of new Xen code has been committed recently and there are probably bugs to find before the release. Keep nagging Amazon to provide more instance types which &os; can run on without paying a "Windows tax". Provide some mechanism for instance configuration via EC2 user-data. This might involve using cloud-init, or it might be a new system. &os; Postmaster Team &os; Postmaster Team postmaster@FreeBSD.org

In the third quarter of 2013, the &os; Postmaster Team has implemented the following items that may be interest of the general public:

 Superpages for ARMv7 Zbigniew Bodek zbb@semihalf.com Grzegorz Bernacki gjb@semihalf.com Rafał Jaworowski raj@semihalf.com

The ARM architecture is becoming more and more prevalent, with increasing usage beyond the mobile and embedded space. Among the more interesting industry trends emerging in the recent months, there has been the concept of "ARM server". Some top-tier companies, e.g. Dell and HP, have already started to develop such systems.

Key to success of &os; in these new areas is dealing with the sophisticated features of the platform, for example adding support for superpages.

The objective of this project is to enable &os;/arm to utilize superpages which would allow efficient use of TLB translations (by enlarging TLB coverage), leading to improved performance in many applications and scalability. This is intended to work on ARMv7-based processors, however compatibility with ARMv6 will be preserved.

The following steps have been made since the last status report:

This project is jointly sponsored by The &os; Foundation and Semihalf.

Adjust pmap to resolve the demotion issue caused by the continuous active queue scanning in VM. Support for 64KB page size. Move pv_flags to page table entry descriptors. &os;/pseries Andreas Tobler andreast@freebsd.org Nathan Whitehorn nwhitehorn@freebsd.org

Starting with &os; 10.0-ALPHA4, the projects/pseries branch has been merged into &os; head. This allows &os;/powerpc64 to run in an IBM POWER logical partition and on certain classes of older IBM-type PowerPC hardware.

Test, possibly on real hardware. Most testing and development was conducted with the emulated LPAR target in QEMU. Please send any testing reports to the freebsd-ppc mailing list. Native iSCSI Stack Edward Tomasz Napierała trasz@FreeBSD.org

Due to the quickly approaching time of 10.0-RELEASE, the priorities for the native iSCSI stack shifted somewhat, from performance optimizations to making sure the new stack is reliable, feature-complete and is able to interoperate correctly with various implementations. Plenty of time was invested into testing and debugging, mostly on the initiator side, to make sure it works correctly with other targets, such as Solaris COMSTAR, and behaves properly in edge conditions, e.g. in case of connection problems. Nevertheless, some fundamental optimizations, such as Immediate Data support, were implemented. Also, the documentation has improved, and there is going to be a new section added to the &os; Handbook that describes the use of the new stack.

The new stack was committed to head and will ship as part of 10.0-RELEASE. There is ongoing work on fixing issues reported by early adopters.

This project is being sponsored by The &os; Foundation.

Fix newly reported issues. Improve performance. SDIO Driver Ilya Bakulin ilya@bakulin.de SDIO Project Page Source Code

SDIO is an interface designed as an extension for the existing SD card standard, to allow connecting different peripherals to the host with the standard SD controller. Peripherals currently sold at the general market include WLAN/BT modules, cameras, fingerprint readers, barcode scanners. The driver is implemented as an extension to the existing MMC bus, adding a lot of new SDIO-specific bus methods. A prototype of the driver for Marvell SDIO WLAN/BT (Avastar 88W8787) module is also being developed, using the existing Linux driver as the reference.

SDIO card detection and initialization already work, most needed bus methods are implemented and tested. There is an ongoing work to design a good locking model for the stack. WiFi driver is able to load a firmware onto the card and initialize it.

SDIO stack: Design a locking model, define how the interrupts should be processed (on SDIO controller level, MMC stack level and by child drivers). Marvell SDIO WiFi: connect to the &os; network stack, write the code to implement required functions (such as sending and receiving data, network scanning, and so on). Implement detach path. It cannot be tested on the DreamPlug used for development, because it does not have an external SDIO-capable slot. Atomic "close-on-exec" Jilles Tjoelker jilles@FreeBSD.org

If threads or signal handlers call fork() and exec(), file descriptors may be passed undesirably to child processes, which may lead to hangs (if a pipe is not closed), exceeding the file descriptor limit and security problems (if the child process has lower privilege). One solution is various new APIs that set the "close-on-exec" flag atomically with allocating a file descriptor. Some existing software will use the new features if present or will even refuse to compile without them.

With mkostemp(), dup3(), and a change to modes of fopen() and freopen(), everything proposed in Austin Group issue #411 has now been implemented. For all POSIX-specified functions that allocate file descriptors, it is possible to request that the new descriptor be set close-on-exec atomically.

Additionally, many file descriptors used internally by libc and libutil now have the close-on-exec bit set.

 Updating <tt>random(4)</tt> Mark Murray markm@freebsd.org Arthur Mesh arthurmesh@gmail.com Dag-Erling Smørgrav des@freebsd.org

Update of random(4) to account for recent revelations, and make more extensible, is in progress.

Fortuna is to be an alternative for Yarrow in FreeBSD 11.x. Yarrow may be deprecated in a couple of years. FIPS 800-90b support is planned. A full, in-depth review of entropy is going to be done with external help. GNUstep on &os; David Chisnall theraven@FreeBSD.org

GNUstep is the open source implementation of the Objective-C APIs based on the OpenStep specification that Apple brands as Cocoa. The similarities between &os; and OS X libc make &os; an attractive target platform for porting OS X applications, with the addition of GNUstep.

The GNUstep ports in &os; have now been updated to the latest releases and now build with the GNUstep Objective-C runtime and Clang 3.3, with the non-fragile ABI by default. This means that all of the modern features of Objective-C are supported, including Automatic Reference Counting (ARC) and recent syntax improvements.

The devel/gnustep meta-port will install all of the core GNUstep libraries, ready for development. The x11/gnustep-app meta-port will install all of the GNUstep-based applications and libraries currently in the ports tree. Many of these are old and not well-tested with later GNUstep release, so consider them experimental at present. We are currently working on updating them, including moving from some abandoned upstream locations to the GNUstep Applications Project (GAP), which has taken over maintenance of a number of older GNUstep programs.

 LLDB Debugger Port Ed Maste emaste@freebsd.org

LLDB is the the debugger project in the LLVM family. It supports the Mac OS X, Linux, and &os; platforms.

A number of improvements have been made to the port since the previous status update. Unit test failures have been triaged and have defects entered in LLDB's bug tracker. In combination with the lldb buildbot this allows for the quick identification of new failures introduced by other ongoing development. Core file support has also been added.

An LLDB snapshot has been imported into the &os; base system and is available as of SVN revision 255722. It is not yet built by default but may be enabled by adding WITH_LLDB= to src.conf(5).

This project is sponsored by DARPA/AFRL in collaboration with SRI International and the University of Cambridge.

Support live debugging of multithreaded processes. Fix amd64 watchpoints. Add support for remote debugging (gdbserver, debugserver). Add support for kernel debugging. Verify i386 and arm architectures. Implement MIPS target support. Verify cross-debugging. Investigate and fix test suite failures. The &os; Foundation Deb Goodkin deb@FreeBSDFoundation.org

The &os; Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the &os; Project and community worldwide. Most of our funding is used to support &os; development projects, conferences and developer summits, purchase equipment to grow and improve the &os; infrastructure, and provide legal support for the Project.

We listened to our donors who asked us to have more fundraising efforts throughout the year. This quarter we had the second of three fundraising campaigns planned for 2013. We started the quarter having raised $365,291. By the end of the quarter, we raised $410,000 for the year. These early donations have made a significant impact on our fundraising efforts this year.

Some of the highlights from this past quarter include:

 Capsicum Pawel Jakub Dawidek pjd@FreeBSD.org

The work on Capsicum and related projects (such as Casper, libnv, etc.) is progressing nicely. An overhaul of the cap_rights_t was committed to &os; head and will be included in 10.0. This allows us to have more capability rights on file descriptors than the previous limit of 64 rights, which was almost reached. This change is not backward compatible, so it was very important to get it into 10.0.

libnv, used for communication between Casper services and consumers, but hopefully will be used more widely, is finalized and comes with a nice set of regression tests.

The number of applications sandboxed using the Capsicum framework is increasing. We have around 10 of them already in base and more that are not yet committed.

This project is being sponsored by the &os; Foundation.

Finish documentation of Casper and its services. Implement regression tests for Casper services. Finish documentation for libnv. Start making libc more sandbox-friendly, that is, functions such as strerror(3), strsignal(3), localtime(3), login_get*(), getservent(3), getprotent(3), getrpcent(3) open files on first use, which might be too late if we are already in a capability-mode sandbox. Rethink the system.filesystem Casper service to allow for easy compartmentalization of various command-line tools that operate on multiple files. GNOME/&os; &os; GNOME Team gnome@FreeBSD.org

Glib 2.36 and Gtk 3.8 were imported into the ports tree. The GNOME Team is currently working on improving the quality of GNOME 3.6. The version of multimedia/cheese shipped with GNOME 3 is now able to use devd(8) to find the camera through multimedia/webcamd. Several build improvements have been made to the www/webkit-gtk3 port, however it still is rather fragile.

MATE is about ready to go in.

GNOME 2 will be removed at some point in the near future. How or when this will happen is not yet clear.

Test the update. Contact the maintainers if it is suspected that a port does not work with the newer version of devel/glib20. Update the &os; GNOME website with recent changes in the ports tree, add new items in preparation for GNOME 3 and Mate, etc. Continue working on GNOME 3.6, stability and missing features. Import MATE into the ports tree. &os; Documentation Project Primer Edit Warren Block wblock@FreeBSD.org

The &os; Documentation Project Primer had not changed at the same rate as the documents themselves. Some sections were outdated, others were wordy and confusing, while information on new changes to the documentation were not described at all. In July, Warren gave the entire FDP Primer a fairly intense edit for simplicity and clarity. Chapters and sections were moved into a more logical order, and information was updated to be a better guide to the current state. Markup examples were added and revised. Style guidelines were also extended and updated. The Primer is now far more consistent and usable. As always, there is still room for improvement, and additions or corrections are encouraged.

An introductory chapter on writing manual pages with mdoc(7) would be an excellent addition. &os;/sparc64 Marius Strobl marius@FreeBSD.org

There are some things going on with &os;/sparc64 port behind the scenes.

For one, after having fixed all remaining problems and starting with 9.2-RELEASE, release bits for this architecture are cross-built on the &os; Project cluster. As one might already have noticed, this means that from now on, sparc64 install sets and images including those for ALPHA, BETA, and RC builds, are already available along with those for the other platforms supported by &os;. It also means that since August 2013, automatically cross-built monthly &os;/sparc64 snapshots are distributed via the official project mirrors. Hopefully, this can be soon extended further with freebsd-update(8) support for sparc64.

Second, the X.Org ports have been fixed to work on sparc64 when built with WITH_NEW_XORG knob. However, it still needs to be evaluated whether the recently committed update to Mesa 9.1.6 has introduced any breakage.

 &os; Port Management Team &os; Port Management Team portmgr@FreeBSD.org

The ports tree contains approximately 24,400 ports, while the PR count exceeds 1,900. In third quarter, we added four new committers and took in six commit bits for safe keeping.

A significant amount of effort has gone into tweaking and manipulating the infrastructure to modernise, and update it, in preperation for pkg(8) replacing the old pkg_* infrastructure, as well as preparing for &os; and Clang as default compiler.

Automated procedures for Quality Assurance have been implemented, notably pkg-fallout. All porters are encouraged to subscribe to the associated mailing list (see links), and do their part to fix ports for pkg(8) and Clang readiness.

Many iterations of tests were run to ensure the maximum amount of packages would be available for the 9.2 release.

Most ports PRs are assigned, we now need to focus on testing, committing, and closing. &os; Core Team &os; Core Team core@FreeBSD.org

In the third quarter of 2013, the Core Team focused on officially launching pkg.freebsd.org, the Project's official pkg(8) repository, in cooperation with the Port Management Team, the Security Team, and the Cluster Administration Team. At the same time, there are plans to gradually deprecate the use of the old pkg_tools, allowing pkg(8) to be the default binary package management solution for &os;, arriving with 10.0-RELEASE. Thomas Abthorpe has been appointed to the role of liaison between the Core Team and the Ports Management Team, in order to make the collaboration more effective.

David Chisnall has joined the group that publishes the Quarterly Status reports and compiled a special status report on the results of the BSDCan 2013 Developer Summit. David also took the lead role on the organization of an off-season developer summit in Cambridge, UK, which was finally held at the end of August. For the items discussed in Cambridge, preparation of a detailed report is still in progress.

There were src commit bits issued for 5 new developers and most of the src commits being idle more than 12 months have been taken into safekeeping as result of a major cleanup in the repository access file in July, performed by Gavin Atkinson.

 X.Org on &os; &os;X11 Team x11@FreeBSD.org X11 Team roadmap (WIP) Ports-related status Ports-related development repository AMD GPU status DRM generic code update branch on GitHub

Mesa 9.1 (libGL and dri) was updated in ports. This includes experimental ports for libEGL and libgles2: they are dependencies of the experimental ports for Wayland and Weston.

The radeonkms driver was committed to &os; head in the end of August and will be part of 10.0-RELEASE. It received several fixes since the initial commit and now it seems quite stable. However, one missing major feature is support for suspend/resume: the GPU almost always locks up during resume on the test computer.

Thanks to the update of Mesa and the update of x11-drivers/xf86-video-ati to 7.2.0 in the ports tree, every pieces are in place to allow users to use recent AMD video cards (up to HD7000, maybe some HD8000).

The driver will now only receive bug fixes and focus will move on the update of the DRM generic code and the i915 driver.

The generic DRM code, shared by the i915kms and radeonkms video drivers is quite old now. Work has started to update and sync it with that of Linux 3.8. This code is available on GitHub.

The expected benefits are:

François Tigeot from DragonFly is also working on updates to their DRM code, and the X11 team is planning to share the effort.

An experimental devd(8) backend was added to the x11-servers/xorg-server port. This allows X.Org to use devd(8) to detect and configure input devices (for example, keyboards and mices) dynamically.

Our current wiki articles are used to describe projects and report status. However, they lack some consistency and links between them. We started to think about reorganizing them to:

Nothing is visible yet on the wiki.

Keep tracking Mesa 9.2 or later and xorg-server 1.14. Both are currently blocked, but it is good to keep track of what upstream is doing. Test and report successes and failures for AMD GPUs. Wayland builds now. Work is being done on Weston to see if there are any run-time issues. Weston is the reference compositor for Wayland. Improve the devd(8) backend for x11-servers/xorg-server, so the HAL option can be removed completely. Continuation of the Newcons Project Aleksandr Rybalko ray@FreeBSD.org Newcons project branch -

The Newcons project is aimed to replace old graphic virtual - terminal named "syscons". The main objectives are: support - Unicode characters and move away from the dependency on fixed - graphic modes (such as VGA and VESA) and built-in services (such - as BIOS).

+

The Newcons project is aimed to replace the old + syscons(4)-based virtual terminals. The main + objectives are: support Unicode characters, and move away from + the dependency on fixed VGA and VESA graphics modes and built-in + BIOS services.

-

This project was started by Ed Schouten originally, and in 2013 - it already featured the following (among many others):

+

This project was originally started by Ed Schouten, and it + already featured the following (among many others) in 2013:

-

And these has been extended by the following items +

And these have been extended by the following items recently:

Supported startup modes for KMS:

This project is being sponsored by The &os; Foundation. Many thanks to Ed Schouten, who started the Newcons project and did - most work.

+ most of the work.

Implement a Generic Framebuffer interface, a simple interface to offer direct access to the framebuffer from the userland (via /dev/fb*) and automatic management of virtual terminals by Newcons. Mouse support, copy/paste using sysmouse(4). Improve locking. Bug fixes. - Integrate into &os; HEAD. + Integrate into &os; head. Integrate into &os; 10.0. Implement mapping non-ASCII characters to Unicode on keyboard input. Adapt existing screen savers. Last but not least, testing is welcome!