diff options
Diffstat (limited to 'en_US.ISO8859-1/htdocs/news/status/report-2018-01-2018-09.xml')
| -rw-r--r-- | en_US.ISO8859-1/htdocs/news/status/report-2018-01-2018-09.xml | 3354 |
1 files changed, 0 insertions, 3354 deletions
diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2018-01-2018-09.xml b/en_US.ISO8859-1/htdocs/news/status/report-2018-01-2018-09.xml deleted file mode 100644 index f878ca1f68..0000000000 --- a/en_US.ISO8859-1/htdocs/news/status/report-2018-01-2018-09.xml +++ /dev/null @@ -1,3354 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for - Status Report//EN" - "http://www.FreeBSD.org/XML/share/xml/statusreport.dtd" > - -<!-- $FreeBSD$ --> -<!-- This file was generated with https://github.com/trasz/md2docbook --> -<!-- - Variables to replace: - %%START%% - report month start - %%STOP%% - report month end - %%YEAR%% - report year - %%NUM%% - report issue (first, second, third, fourth) - %%STARTNEXT%% - report month start - %%STOPNEXT%% - report month end - %%YEARNEXT%% - next report due year (if different than %%YEAR%%) - %%DUENEXT%% - next report due date (i.e., June 6) ---> - -<report> - <date> - <month>%%START%%-%%STOP%%</month> - - <year>%%YEAR%%</year> - </date> - - <section> - <title>Introduction</title> - - <p>With &os; having gone all the way to 12, it is perhaps - useful to take a look back at all the things that have been - accomplished, in terms of many visible changes, as well as all - the things that happen behind the scenes to ensure that &os; - continues to offer an alternative in both design, - implementation, and execution.</p> - - <p>The things you can look forward to reading about are too - numerous to summarize, but cover just about everything from - finalizing releases, administrative work, optimizations - and depessimizations, features added and fixed, and many areas - of improvement that might just surprise you a little.</p> - - <p>Please have a cup of coffee, tea, hot cocoa, or other beverage - of choice, and enjoy this culmulative set of reports covering - everything that's been done since October, 2017.</p> - - <p>—Daniel Ebdrup</p> - </section> - - <category> - <name>team</name> - - <description>&os; Team Reports</description> - - <p>Entries from the various official and semi-official teams, - as found in the <a href="&enbase;/administration.html">Administration - Page</a>.</p> - </category> - - <category> - <name>proj</name> - - <description>Projects</description> - - <p>Projects that span multiple categories, from the kernel and userspace - to the Ports Collection or external projects.</p> - </category> - - <category> - <name>arch</name> - - <description>Architectures</description> - - <p>Updating platform-specific features and bringing in support - for new hardware platforms.</p>. - </category> - - <category> - <name>ports</name> - - <description>Ports</description> - - <p>Changes affecting the Ports Collection, whether sweeping - changes that touch most of the tree, or individual ports - themselves.</p> - </category> - - <category> - <name>doc</name> - - <description>Documentation</description> - - <p>Noteworthy changes in the documentation tree or new external - books/documents.</p> - </category> - - <category> - <name>third</name> - - <description>Third-Party Projects</description> - - <p>Many projects build upon &os; or incorporate components of - &os; into their project. As these projects may be of interest - to the broader &os; community, we sometimes include brief - updates submitted by these projects in our quarterly report. - The &os; project makes no representation as to the accuracy or - veracity of any claims in these submissions.</p> - </category> - - <project cat='team'> - <title>Release Engineering Team</title> - - <contact> - <person> - <name>FreeBSD Release Engineering Team</name> - <email>re@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="https://www.FreeBSD.org/releases/10.4R/announce.html">FreeBSD 10.4-RELEASE announcement</url> - <url href="https://www.FreeBSD.org/releases/11.2R/announce.html">FreeBSD 11.2-RELEASE announcement</url> - <url href="https://www.FreeBSD.org/releases/12.0R/schedule.html">FreeBSD 12.0-RELEASE schedule</url> - <url href="https://download.FreeBSD.org/ftp/snapshots/ISO-IMAGES/">FreeBSD development snapshots</url> - </links> - - <body> - <p>The FreeBSD Release Engineering Team responsibilities - include:</p> - - <ul> - <li>setting and publishing release schedules for official - project releases of FreeBSD</li> - - <li>announcing code slushes, freezes, and thaws</li> - - <li>maintaining the respective branches for all supported - releases</li> - </ul> - - <p> - The FreeBSD Release Engineering Team, led by Marius - Strobl, - completed the 10.4-RELEASE in early October 2017. FreeBSD - 10.4-RELEASE was the - fifth release from the <tt>stable/10</tt> branch, which - built on the - stability and reliability of 10.3-RELEASE.</p> - - <p>The FreeBSD 11.2-RELEASE cycle started April 20, 2018 with - the - announcement of the code slush. The first stage progress - was - continued throughout the rest of the quarter with the code - freeze, - followed by three BETA builds, three RC builds, and the - final release - build was announced June 27, 2018.</p> - - <p>The FreeBSD Release Engineering Team started the - 12.0-RELEASE cycle - August 10, 2018 with the announcement of the code slush. - The code - freeze followed on August 24, 2018. The tentative date for - the <tt>stable/12</tt> branch was expected to be September 21, - 2018.</p> - - <p> - Due to unforeseen circumstances with upstream code that - was necessary - to include in 12.0-RELEASE, the tentative release schedule - needed - to be adjusted several times. The API changes in the - updated version - of the upstream code required changes to be made for all - base system - utilities that linked with the upstream code. By the end - of the - 2018Q3 quarter, the <tt>stable/12</tt> branch had not been - created due to - this delay.</p> - - <p>Throughout the remainder of 2018Q3, several development - snapshots builds - were released for the <tt>head</tt>, <tt>stable/11</tt>, - and <tt>stable/10</tt> branches.</p> - - <p>Much of this work was sponsored by the FreeBSD Foundation.</p> - - </body> - - </project> - - <project cat='team'> - <title>Ports Collection</title> - - <contact> - <person> - <name>René Ladan</name> - <email>portmgr-secretary@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="https://www.FreeBSD.org/ports/">About FreeBSD Ports</url> - <url href="https://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html">Contributing to ports</url> - <url href="http://portsmon.FreeBSD.org/index.html">FreeBSD ports monitoring</url> - <url href="https://www.FreeBSD.org/portmgr/index.html">Ports Management Team</url> - <url href="https://twitter.com/freebsd_portmgr/">FreeBSD portmgr (@freebsd_portmgr)</url> - <url href="https://www.facebook.com/portmgr">FreeBSD Ports Management Team (Facebook)</url> - <url href="https://plus.google.com/communities/108335846196454338383">FreeBSD Ports Management Team (Google+)</url> - </links> - - <body> - <p>During the first quarter of 2018, the number of ports grew - to almost 32,000. - In 2018Q1, there were - 2,100 open PRs with fewer than 600 unassigned. There were - 7,900 commits from 169 committers. Compared to last - quarter, the number - of commits grew by 18% and the number of PRs dropped by - 25%. Those are - some good numbers!</p> - - <p>During the 2018Q2 and 2018Q3 quarters, the number of ports - grew to just under - 34,000. The number of open PR grew to almost 2,500 with - fewer than 600 - of those unassigned. A total of 175 committers made almost - 14,200 commits. - Compared to the first quarter, the number of commits - dropped by 10% and - the number of PRs grew by 19%.</p> - - <p>During the last three quarters, portmgr took twelve commit - bits in for - safekeeping: daichi@, deichen@, ian@, junovitch@, kevlo@, - maho@, nemysis@, - pawel@, rea@, tabthorpe@, vg@, and wxs@.</p> - - <p>Portmgr welcomed thirteen new committers in 2018Q2 and - 2018Q3:</p> - - <ul> - <li>Devin Teske (dteske@)</li> - - <li>Eric Turgeon (ericbsd@)</li> - - <li>Fernando Apesteguía (fernape@)</li> - - <li>Fukang Chen (loader@)</li> - - <li>Gleb Popov (arrowd@)</li> - - <li>Jesper Schmitz Mouridsen (jsm@)</li> - - <li>John Hixson (jhixson@)</li> - - <li>Kevin Bowling (kbowling@)</li> - - <li>Koichiro IWAO (meta@)</li> - - <li>Mateusz Piotrowski (0mp@)</li> - - <li>Matthias Fechner (mfechner@)</li> - - <li>Sergey Kozlov (skozlov@)</li> - </ul> - - <p> - The following committers returned after a hiatus:</p> - - <ul> - <li>Ion-Mihai Tetcu (itetcu@)</li> - - <li>Kevin Lo (kevlo@)</li> - - <li>Sean Chittenden (seanc@)</li> - </ul> - - <p> - During the last three quarters, Antoine Brodin (antoine@) - ran no - fewer than 113 exp-runs against the ports tree. These runs - were - executed to test updates, perform cleanups, and make - improvements - to the framework and the base system. Most of the runs - were for - port upgrades, but others include LLD progress, changes to - the - default port versions, improved support for armv6, armv7, - and RISC-V - architectures, removed old base system functionality, new - USES, and - better matching pkg-plist with Makefile options (DOCS and - EXAMPLES).</p> - - <p>Five new USES values were introduced:</p> - - <ul> - <li>apache: handle dependencies on the Apache web server and - modules</li> - - <li>eigen: automatically depend on math/eigen2 or math/eigen3</li> - - <li>emacs: handle dependencies on the Emacs editor and - modules.</li> - - <li>gl replaces the old USE_GL from bsd.port.mk</li> - - <li>qt-dist, qt:4 and qt:5 replace the old USE_QT from - bsd.qt.mk</li> - </ul> - - <p> - The EXTRA_PATCHES functionality has been extended to - support - directories, where it will automatically apply all - patch-\* files to the port.</p> - - <p>Ports using USES=php:phpize, php:ext, php:zend, and - php:pecl have - been flavored and packages are now automatically built - for all - versions of PHP that are supported (5.6, 7.0, 7.1 or 7.2).</p> - - <p>2018Q3 had updates of major ports: pkg 1.10.5, Chromium - 65.0.3325.181, Firefox 59.0.2, Firefox-ESR 52.7.3, Ruby - 2.3.7/2.5.1 - and Qt5 5.9.4. - The default version of PHP was changed from 5.6 to 7.1. - The former - version of PHP is no longer supported by the developers. - The - default versions of Samba and GCC are now respectively 4.7 - and 7. The - Xorg ports have been reorganized and there have been - changes to - net/openntpd. Please review the UPDATING file for relevant - details.</p> - - <p>Open tasks:</p> - - <ul> - <li>The number of commits dropped somewhat over the last three - quarters, - leaving more PRs unresolved. If possible, please pick up - some PRs - and improve everyone's experience.</li> - </ul> - - </body> - - </project> - - <project cat='team'> - <title>Core Team</title> - - <contact> - <person> - <name>FreeBSD Core Team</name> - <email>core@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>Much of Core's focus for the past months has been on three - items:</p> - - <p>1. Coordination between different groups to support the - upcoming 12.0 release. The timing of the OpenSSL - 1.1.1 release posed challenges. The new OpenSSL - version included API changes, so many components of - the base system and ports required changes. - Staying with the older OpenSSL in 12.0 was not a - feasible option, because it would have meant - backporting many changes to a version of OpenSSL - that would be unmaintained by the upstream source.</p> - - <p>2. Discussions with the release engineering team and Scott - Long about updating the FreeBSD release process. - Topics for exploration include:</p> - - <ul> - <li>having more frequent point releases</li> - - <li>changing the support model</li> - - <li>revising and improving the tooling used to manage the tree - and releases</li> - - <li>additional topics as they are discovered</li> - </ul> - - <p>3. Gathering information to make decisions more - data-driven. For example, we are planning - developer and user surveys. If there are questions - that you think should be added to the survey, - please discuss them on freebsd-arch@. We are - also exploring ways to collect automated hardware-usage data. - This will help the project to understand the changing ways our - software is used and to improve hardware support.</p> - - <p>Here are other noteworthy events (in chronological order) - since the last quarterly report.</p> - - <p>2017 Q4</p> - - <ul> - <li>Sean Eric Fagan's (sef@) commit bit was reactivated with a - period of re-mentoring under Alexander Motin - (mav@).</li> - - <li>The MIPS architecture was promoted to tier 2 status.</li> - - <li>Core approved changes to the Code of Conduct.</li> - - <li>All fortune data files, except freebsd-tips, were removed - in r325828.</li> - - <li>Core approved the adoption of a policy requiring any - license exceptions to be recorded alongside code.</li> - - <li>Gordon Tetlow (gordon@) became the new security officer.</li> - - <li>Core approved the use of SPDX tags.</li> - </ul> - - <p>2018 Q1</p> - - <ul> - <li>Jeb Cramer (jeb@) was awarded a src commit bit under the - mentorship of Sean Bruno (sbruno@) and Eric Joyner - (erj@).</li> - - <li>Members of the CoC Review Team were approved. The - membership is to be reviewed once per year.</li> - - <li>A vendor commit bit was awarded to Slava Shwartsman - (slavash@) of Mellanox Technologies under the - mentorship of Konstantin Belousov (kib@) and Hans - Petter Selasky (hselasky@).</li> - - <li>Walter Schwarzenfeld was awarded project membership.</li> - - <li>Brad Davis (brd@) was awarded a src commit bit under the - mentorship of Allan Jude (allanjude@) with - Baptiste Daroussin (bapt@) as co-mentor.</li> - - <li>Vincenzo Maffione (vmaffione@) was awarded a src commit - bit under the mentorship of Hiroki Sato (hrs@).</li> - - <li>Ram Kishore Vegesna (ram@) was awarded a src commit bit - under the mentorship of Kenneth D. Merry (ken@) - and Alexander Motin (mav@).</li> - </ul> - - <p>2018 Q2</p> - - <ul> - <li>Tom Jones (thj@) was awarded a src commit bit under the - mentorship of Jonathan T. Looney (jtl@).</li> - - <li>Matt Macy's (mmacy@) commit bit was restored under the - mentorship of Sean Bruno (sbruno@).</li> - - <li>Breno Leitao (leitao@) was awarded a src commit bit under - the mentorship of Justin Hibbits (jhibbits@) with - Nathan Whitehorn (nwhitehorn@) as co-mentor.</li> - - <li>Leandro Lupori (luporl@) was awarded a src commit bit - under the mentorship of Justin Hibbits (jhibbits@) - with Nathan Whitehorn (nwhitehorn@) as co-mentor.</li> - - <li>The handover from the ninth to the tenth elected Core team - took place. The tenth Core members are: Allan Jude - (allanjude@), Benedict Reuschling (bcr@), Brooks - Davis (brooks@), Hiroki Sato (hrs@), Warner Losh - (imp@), Jeff Roberson (jeff@), John Baldwin - (jhb@), Kris Moore (kmoore@), and Sean Chittenden - (seanc@).</li> - - <li>Joseph Mingrone (jrm@) was appointed the Core secretary - under mentorship of the retiring Core secretary, - Matthew Seaman (matthew@).</li> - - <li>The new team liaisons were decided. portmgr: Sean, doceng: - Hiroki, secteam: Brooks, re: John, clusteradm: - Allan, CoC: Warner, Foundation: Benedict, - bugmeister: John, CI: Sean.</li> - - <li>David Maxwell (dwm@) was awarded project membership.</li> - - <li>Daichi Goto's (daichi@) commit bit was reactivated with a - period of re-mentoring under George Neville-Neil - (gnn@).</li> - - <li>A vendor commit bit was awarded to Ben Widawsky - (bwidawsk@) of Intel under the mentorship of Ed - Maste (emaste@).</li> - </ul> - - <p> - 2018 Q3</p> - - <ul> - <li>Core decided to begin meeting twice per month in an - attempt to catch up with many new agenda items.</li> - - <li>Li-Wen Hsu (lwhsu@) was awarded a src commit bit under the - mentorship of Mark Johnston (markj@) with Ed Maste - (emaste@) as co-mentor.</li> - - <li>Samy al Bahra was awarded project membership.</li> - - <li>George Neville-Neil (gnn@) was approved to begin - co-mentoring Vincenzo Maffione (vmaffione@).</li> - </ul> - - </body> - - </project> - - <project cat='team'> - <title>The FreeBSD Foundation</title> - - <contact> - <person> - <name>Deb Goodkin</name> - <email>deb@FreeBSDFoundation.org</email> - </person> - </contact> - - <body> - <p>The FreeBSD Foundation is a 501(c)(3) non-profit - organization dedicated to supporting and promoting - the FreeBSD Project and community worldwide. - Funding comes from individual and corporate - donations and is used to fund and manage software - development projects, conferences and developer - summits, and provide travel grants to FreeBSD - contributors. The Foundation purchases and - supports hardware to improve and maintain FreeBSD - infrastructure and provides resources to improve - security, quality assurance, and release - engineering efforts; publishes marketing material - to promote, educate, and advocate for the FreeBSD - Project; facilitates collaboration between - commercial vendors and FreeBSD developers; and - finally, represents the FreeBSD Project in - executing contracts, license agreements, and other - legal arrangements that require a recognized legal - entity.</p> - - <p>Here are some highlights of what the FreeBSD Foundation - did to help FreeBSD last quarter:</p> - - <p>Partnerships and Commercial User Support</p> - - <p>As a 501(c)(3) non-profit, we don't directly support - commercial users, but we do work with them to - understand their needs and help facilitate - collaboration with the community. Last quarter we - met with a few key FreeBSD users and supporters, - to discuss pain points, how they can contribute - back to FreeBSD, and what technologies they would - like to see supported, to support FreeBSD over - more of their technologies and products.</p> - - <p>As many of you know, we formed a partnership with Intel - around one and a half years ago. Since then the - people we worked directly with left the company, - but it moved us into a new relationship with their - Open Source Technology Center (OTC).</p> - - <p>We are very encouraged that Intel has dedicated additional - resources from the OTC to work on FreeBSD in - addition to existing resources from the networking - group and other technologies such as QuickAssist. - Much of the work has been focused on security and - OS mitigations but we're also focusing on other - areas such as power management and persistent - memory. In May and again in July we traveled to - Intel's Hillsboro campus to meet with management - and engineers from OTC and the networking team. We - presented an overview of the project and - Foundation and also discussed key markets and - vendors who use FreeBSD in their products or - services and their future requirements.</p> - - <p>Intel was also interested in learning more about who - contributes to FreeBSD. Along those lines we've - done some work with OTC to create scripts and - organizational mappings to answer that question. - Note that we do need developers - to help us update and maintain the organizational - mappings as we understand that developers do tend - to move around and contractors are often working - on behalf of multiple organizations.</p> - - <p>Fundraising Efforts</p> - - <p>Our work is 100% funded by your donations. As of September - 30, we raised $328,482. Our 2018 fundraising goal - is $1,250,000 and we are continuing to work hard to - meet and exceed this goal! Please consider making - a donation to help us continue and increase our - support for FreeBSD: <a - href="https://www.FreeBSDfoundation.org/donate/">https://www.FreeBSDfoundation.org/donate/</a>.</p> - - <p>We also have a new Partnership Program, to provide more - benefits for our larger commercial donors. Find - out more information at <a - href="https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/">https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/</a> - and share with your companies!</p> - - <p>OS Improvements</p> - - <p>The Foundation improves the FreeBSD operating system by - employing technical staff to maintain and improve - critical kernel subsystems, add features and - functionality, and fix problems. This also - includes funding separate project grants like the - arm64 port, porting the blacklistd access control - daemon, and the integration of VIMAGE support, to - make sure that FreeBSD remains a viable solution - for research, education, computing, products and - more.</p> - - <p>We kicked off or continued the following projects last - quarter:</p> - - <ul> - <li>OpenZFS RAID-Z Expansion project</li> - - <li>Headless mode out-of-the-box for embedded ARM boards like - the Beaglebone Black</li> - - <li>Performance and scalability improvements</li> - </ul> - - <p> - Having software developers on staff has allowed us to jump - in and work directly on projects to improve - FreeBSD such as:</p> - - <ul> - <li>ZFS improvements</li> - - <li>New Intel server support</li> - - <li>kqueue(2) updates</li> - - <li>64-bit inode support</li> - - <li>Stack guard</li> - - <li>Kernel Undefined Behavior Sanitizer</li> - - <li>Toolchain projects</li> - - <li>i915 driver investigation</li> - - <li>NVDIMM support in acpiconf(8)</li> - - <li>Continuous integration dashboard (web page and physical - hardware)</li> - - <li>FAT filesystem support in makefs(8)</li> - </ul> - - <p> - Continuous Integration and Quality Assurance</p> - - <p>The Foundation provides a full-time staff member who is - working on improving our automated testing, - continuous integration, and overall quality - assurance efforts.</p> - - <p>Foundation employee Li-Wen Hsu set up new CI servers to - speed up amd64 build and test jobs, to reduce the - latency between changes being committed and - results being available. Li-Wen also set up a - staging / development server in order to test - changes to the CI system itself without affecting - production results. We have also started a small - hardware test lab, currently connected to the - staging server, that tests the full boot and test - cycle on physical hardware. In the near future - additional hardware devices will be added, and - this will migrate to the production CI server.</p> - - <p>Release Engineering</p> - - <p>The Foundation provides a full-time staff member to lead - the release engineering efforts. This has provided - timely and reliable releases over the last five - years.</p> - - <p>Foundation employee Glen Barber continued leading the - efforts on the upcoming 12.0-RELEASE. For details - surrounding the work involved and progress thus - far on 12.0-RELEASE, please see the FreeBSD - Release Engineering Team section of this quarterly - status report.</p> - - <p>Supporting FreeBSD Infrastructure</p> - - <p>The Foundation provides hardware and support to improve - the FreeBSD infrastructure. Last quarter, we - continued supporting FreeBSD hardware located - around the world.</p> - - <p>FreeBSD Advocacy and Education</p> - - <p>A large part of our efforts are dedicated to advocating - for the Project. This includes promoting work - being done by others with FreeBSD; producing - advocacy literature to teach people about FreeBSD - and help make the path to starting using FreeBSD - or contributing to the Project easier; and - attending and getting other FreeBSD contributors - to volunteer to run FreeBSD events, staff FreeBSD - tables, and give FreeBSD presentations.</p> - - <p>The FreeBSD Foundation sponsors many conferences, events, - and summits around the globe. These events can be - BSD-related, open source, or technology events - geared towards underrepresented groups. We support - the FreeBSD-focused events to help provide a venue - for sharing knowledge, to work together on - projects, and to facilitate collaboration between - developers and commercial users. This all helps - provide a healthy ecosystem. We support the - non-FreeBSD events to promote and raise awareness - of FreeBSD, to increase the use of FreeBSD in - different applications, and to recruit more - contributors to the Project.</p> - - <p>Check out some of the advocacy and education work we did - last quarter:</p> - - <ul> - <li>Organized and ran the Essen FreeBSD Hackathon in Essen, - Germany</li> - - <li>Participated in the FreeBSD Developer Summit BSDCam, in - Cambridge, England</li> - - <li>Represented FreeBSD at the ARM Partner Meeting</li> - - <li>Presented and taught about FreeBSD at SdNOG 5 in Khartoum, - Sudan</li> - - <li>Exhibited and gave a talk at OSCON 2018 in Portland, OR</li> - - <li>Exhibited at the 2018 Grace Hopper Celebration and - sponsored as a Silver Non-Profit Sponsor</li> - - <li>Exhibited at COCON 2018 in Taipei, Taiwan</li> - - <li>Sponsored and gave presentations and tutorials at - EuroBSDCon in Bucharest, Romania</li> - - <li>Organized and ran the Bucharest FreeBSD Developer Summit</li> - - <li>Sponsored the 2018 USENIX Security Symposium in Baltimore, - MD as an Industry Partner</li> - - <li>Provided FreeBSD advocacy material</li> - - <li>Sponsored the 2018 USENIX Annual Technical Conference in - Boston, MA as an Industry Partner</li> - - <li>Sponsored the OpenZFS Developer Summit as a Silver Sponsor</li> - - <li>Presented and taught about FreeBSD at SANOG32 in Dhaka, - Bangladesh</li> - - <li>Sponsored the SNIA Storage Developer Conference 2018 as an - Association Partner</li> - - <li>Provided 11 travel grants to FreeBSD contributors to - attend many of the above events.</li> - </ul> - - <p> - We continued producing FreeBSD advocacy material to help - people promote FreeBSD around the world.</p> - - <p>Read more about our conference adventures in the - conference recaps and trip reports in our monthly - newsletters: <a - href="https://www.freebsdfoundation.org/news-and-events/newsletter/">https://www.freebsdfoundation.org/news-and-events/newsletter/</a></p> - - <p>We help educate the world about FreeBSD by publishing the - professionally produced FreeBSD Journal. Last - quarter we published the July/August issue that - you can find at <a - href="https://www.FreeBSDfoundation.org/journal/">https://www.FreeBSDfoundation.org/journal/</a>.</p> - - <p>You can find out more about events we attended and - upcoming events at <a - href="https://www.FreeBSDfoundation.org/news-and-events/">https://www.FreeBSDfoundation.org/news-and-events/</a>.</p> - - <p>Legal/FreeBSD IP</p> - - <p>The Foundation owns the FreeBSD trademarks, and it is our - responsibility to protect them. We also provide - legal support for the core team to investigate - questions that arise.</p> - - <p>Go to <a - href="http://www.FreeBSDfoundation.org">http://www.FreeBSDfoundation.org</a> - to find out how we support FreeBSD and how we can - help you!</p> - - </body> - - </project> - - <project cat='team'> - <title>Continuous Integration</title> - - <contact> - <person> - <name>Jenkins Admin</name> - <email>jenkins-admin@FreeBSD.org</email> - </person> - <person> - <name>Li-Wen Hsu</name> - <email>lwhsu@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="https://ci.FreeBSD.org">FreeBSD Jenkins Instance</url> - <url href="https://artifact.ci.FreeBSD.org/">FreeBSD CI artifact archive</url> - <url href="https://wiki.FreeBSD.org/Jenkins">FreeBSD Jenkins wiki</url> - <url href="https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing">freebsd-testing Mailing List</url> - <url href="https://github.com/freebsd/freebsd-ci">freebsd-ci Repository</url> - </links> - - <body> - <p>The FreeBSD CI team maintains continuous integration tasks - for FreeBSD. The CI - system regularly checks the changes committed to the - project's Subversion - repository can be successfully built, and performs various - tests and analysis - with the build results. The CI team also maintains the - archive of the artifact - built by the CI system, for the further testing and - debugging needs.</p> - - <p>Starting from June 2018, the project is sponsored by the - FreeBSD Foundation in - hardware and staff. For more details of the sponsored - projects, please refer - to:</p> - - <p><a - href="https://www.freebsdfoundation.org/news-and-events/newsletter/freebsd-foundation-update-september-2018/">https://www.freebsdfoundation.org/news-and-events/newsletter/freebsd-foundation-update-september-2018/</a></p> - - <p>In addition to that, we also helped checking regressions - for OpenSSL 1.1.1 - update and test continuously for 12-STABLE branch.</p> - - <p>We had meetings and working groups at two developer - summits during 2018Q3:</p> - - <ul> - <li><a - href="https://wiki.FreeBSD.org/DevSummit/201808/Testing">BSDCam - 2018</a></li> - - <li><a - href="https://wiki.FreeBSD.org/DevSummit/201809">EuroBSDCon - 2018</a></li> - </ul> - - <p> - Work in progress:</p> - - <ul> - <li>Fixing the failing test cases and builds</li> - - <li><a - href="https://ci.FreeBSD.org/job/FreeBSD-head-amd64-dtrace_test/lastCompletedBuild/testReport/">DTrace - test</a></li> - - <li><a - href="https://ci.FreeBSD.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/">ZFS - test</a></li> - - <li><a - href="https://ci.FreeBSD.org/job/FreeBSD-head-amd64-gcc/">GCC - build</a></li> - - <li>Adding drm ports building test against -CURRENT</li> - - <li>Adding tests for selected project branches, e.g.: - clang700-import</li> - - <li>Adding new hardware to the embedded testbed</li> - - <li>Implementing automatic tests on bare metal hardware</li> - - <li>Planning running ztest and network stack tests</li> - </ul> - - </body> - - </project> - - <project cat='proj'> - <title>4G/4G address space split for i386</title> - - <contact> - <person> - <name>Konstantin Belousov</name> - <email>kib@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>Most 32-bit FreeBSD architectures, including i386, started - to suffer - from the rapid growth of the size of software during the - past decade. - When a 32-bit address space is enough space for a given - task, 32-bit - mode still has an intrinsic advantage over 64-bit mode, - due to less - memory traffic and more economical use of caches. It has - grown - harder to provide the self-hosting i386 system build due - to the - increase in size of the build tools.</p> - - <p>The FreeBSD i386 kernel, prior to the 12.0-RELEASE - version, split - the 4GB address space of the platform into 3GB (minus 4MB) - accessible - to userspace accesses and 1GB for kernel accesses. - Neither kernel nor userspace could access a full 4GB - address space. - Programs that require very large virtual address spaces, - such as - clang when compiling or lld when linking, could run out of - address - space: 3GB of address space was insufficient for their - operation. - The kernel also had trouble fitting into the traditional - 1GB - limitation of address space with the modern sizing for - network - buffers, ZFS and other KVA-hungry in-kernel subsystems.</p> - - <p>In FreeBSD 12, the i386 architecture has been changed to - provide - dedicated separate address spaces for userspace and - kernel, giving - each mode full access to 4GB (minus 8MB) of usable address - space. - The userspace on the i386 architecture now has access to - the same - amount of address space as the compat32 subsystem in the - amd64 - architecture kernel. The increase in kernel address space - enables - further growth and maintainability of the i386 - architecture.</p> - - <p>The split 4GB/4GB user/kernel implementation uses two page - directory - entries (PDEs) shared between modes: one for mapping the - page table, - another for the mode switching trampoline and other - required system - tables. The required system tables, which must always be - mapped, - regardless of kernel or user mode, includes such things as - the - GDT/IDT/TSS entries. Significant changes were made to the - locore - code. The page table creation portion of the code was - completely - rewritten from assembly to C, improving readability and - maintainability - of the code.</p> - - <p>Because the user address space is no longer shared with - the kernel, - the copyout(9) functions were rewritten to make a - transient mapping - of userspace pages for the duration of any needed - accesses. The initial - implementation used the vm_fault_quick_hold_pages() - framework, but - this was later optimized by temporarily switching to user - mode - mappings from a trampoline, and then using hand-written - assembler - routines to perform a faster small block copy operation.</p> - - <p>Future plans for the ongoing maintenance of i386 include - making the i386 pmap - capable of runtime selection of the PAE or non-PAE page - table format - and supporting NX (no execute) mappings for regular i386 - kernel.</p> - - </body> - - <sponsor> - The FreeBSD Foundation - </sponsor> - - </project> - - <project cat='proj'> - <title>FreeBSD/DTrace</title> - - <contact> - <person> - <name>George Neville-Neil</name> - <email>gnn@FreeBSD.org</email> - </person> - <person> - <name>Domagoj Stolfa</name> - <email>domagoj.stolfa@cl.cam.ac.uk</email> - </person> - </contact> - - <body> - <p>DTrace is a whole-system debugging tool in FreeBSD and is - one of the - actively supported projects during the past year.</p> - - <p>A research prototype of a distributed version of DTrace - and a version - of DTrace that can trace bhyve virtual machines from the - host FreeBSD - system are currently under development at the University - of Cambridge - as a part of the CADETS project. Recent developments - include the - creation of dlog, an in-kernel DTrace consumer which is - able to - publish to Kafka, and improvements to early boot and - shutdown tracing. - On the virtualisation front, - improvements were made in the ability to dereference and - follow - pointers inside guests from the host in the probe context - by - implementing a nested page table walk inside DTrace for - Intel - architectures. The CADETS project has started formalizing - DTrace in HOL4 which enables automated test generation, - high assurance - of DTrace implementations in terms of adherence to the - specification - and exploration of all allowable behaviors for a given D - script. Currently, the formal model contains most of DIF - instructions - and a code generator for them, providing the ability to - run DIF - programs specified using the model using FreeBSD's DTrace - implementation.</p> - - <p>As a result of all of this, a number of changes were - upstreamed to the - FreeBSD auditing subsystem and new variables such as - <tt>jid</tt> and - <tt>jailname</tt> were added to DTrace which can be - accessed from D scripts.</p> - - <p>OpenDTrace Specification 1.0 has been published which - covers the - internal workings of DTrace in general, and its adaptation - to various - operating systems in particular. This work was sponsored - by - AFRL/DARPA through the CADETS project.</p> - - <p>Ruslan Bukin (br@) has added C-compressed ISA extension - support to the - RISC-V FBT provider as a part of the ECATS project.</p> - - <p>Mark Johnston (markj@) has done some work to fix - interactions between - FBT and ifuncs. ifuncs are a toolchain feature which allow - programmers - to select a function's implementation at boot-time, rather - than at - compile-time. For instance, on amd64, memcpy() is an ifunc - and may be - implemented by either memcpy_erms() or memcpy_std(). FBT - created - probes for the implementation functions, but we needed - some extra - support to ensure that fbt::memcpy:entry continues to work - as - expected. Similar work is needed for the PID provider, but - is still - pending.</p> - - <p>Microsoft showed a <a - href="https://youtu.be/tG8R5SQGPck?t=891">working - demo of DTrace</a>, - which was ported from FreeBSD.</p> - - <p>Added to FreeBSD base in 11.2, dwatch is a new DTrace - tool, developed - by Devin Teske (dteske@), for automating complex queries - for data and - surgically tapping the kernel. In base there are 85 - profiles for - interpreting domain-specific data with another 17 - available from ports - making a total of over 100 different pipelines from which - you can - extract data in multiple formats. dwatch also simplifies - observation - of over 100,000 probe points available in FreeBSD, making - it easy to - find any process, thread, or jail triggering any probe. - On top of all - that, dwatch profiles can leverage higher-level languages - such as - python, perl, sh, and many more.</p> - - </body> - - </project> - - <project cat='proj'> - <title>ACPI NVDIMM driver</title> - - <contact> - <person> - <name>Konstantin Belousov</name> - <email>kib@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>NVDIMM is a technology which provides non-volatile memory - with - access characteristics similar to regular DRAM, which is - the - technology that implements the normal memory address space - of a host. - There are ACPI and UEFI specifications that define - platform independent - ways to detect and enumerate the presence of NVDIMMs. - These - specifications allow the retrieval of most of the data - needed to - allow proper application use of the NVDIMM storage.</p> - - <p>A new FreeBSD driver parses the ACPI NFIT table which - lists NVDIMMs, - their operational characteristics, and the physical - address space - where the NVDIMM memory is accessible. The driver presents - each - address region as two devices: One device allows userspace - to - open(2) a devfs node, which can be read/written/mapped - from the - application. This mapping is zero-copy. The second device - is a - geom disk(9), which makes it possible to use NVDIMM for - the backing - storage for a normal FreeBSD filesystem, such as UFS, ZFS, - or msdosfs. - Note that buffer cache/mapping of files from a traditional - filesystem - created over NVDIMM causes an unneeded double-buffering.</p> - - <p>Empirically, on typical modern hardware, NVDIMM regions - are located - far from the regular DRAM backed memory in the address - space, and - have attributes that are not compatible with regular DRAM - memory. - This makes it unfeasible to extend the kernel's direct map - to provide - the kernel mappings for the NVDIMM regions. - A new pmap KPI was designed, pmap_large_map(9), - which allows efficient mapping of very large physical - regions into - the KVA. The new code has some optimizations to the cache - flushing - operations over the mapped regions, which is needed to - efficiently - support bio flushes from a filesystems using the NVDIMM - storage. - The NVDIMM driver is the first user of the new KPI, - but the new KPI might also be useful for the NTB driver.</p> - - <p> - TODO:</p> - - <ul> - <li>Intel is currently working on extending the driver to - support - UEFI namespaces.</li> - - <li>A DAX-capable filesystem is needed, which solves the issue - of - double-buffering. Our tmpfs already provides VM facilities - which - allows it to avoid double-buffering for mmap, which can be - reused - there.</li> - </ul> - - </body> - - <sponsor> - The FreeBSD Foundation - </sponsor> - - </project> - - <project cat='proj'> - <title>SMAP</title> - - <contact> - <person> - <name>Konstantin Belousov</name> - <email>kib@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>Support for SMAP (Supervisor-Mode Access Prevention), has - been added - to the amd64 kernel. The SMAP feature makes any access - from the - supervisor mode to the pages accessible to user mode cause - a fault, - unless the %eflags.AC bit is set at the time of the - access.</p> - - <p>The SMAP implementation uses the ifunc framework to avoid - checking - for the SMAP capability of hardware on each call to - copyout(9) and - other functions.</p> - - <p>In the amd64 architecture, FreeBSD has a common address - space between - the kernel space and user space. Enabling SMAP virtually - splits - the shared address space into two disjoint address spaces, - which - have different access criteria. This splitting of the - address space - provides a relatively low-overhead way of catching direct - accesses - from kernel to usermode, when not using the copyout(9) - family of - functions. The copyout(9) family of functions are - permitted direct - access to user space. Any direct access from kernel mode - to user - address space that isn't performed through the copyout(9) - family - of functions indicates a potential programming error.</p> - - <p>It is interesting that very few bugs were found in the - FreeBSD - kernel after the SMAP feature was enabled. One issue that - was - identified existed in the pci(9) user driver. Enabling the - SMAP - feature identified at least two ports, VBox and acpi_call, - which - appeared to access userspace in an unsafe manner.</p> - - </body> - - <sponsor> - The FreeBSD Foundation - </sponsor> - - </project> - - <project cat='proj'> - <title>Large scale package building</title> - - <contact> - <person> - <name>Mateusz Guzik</name> - <email>mjg@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>Building packages on a 128-thread machine with poudriere - exhibits some - bottlenecks.</p> - - <p>See the October FreeBSD Foundation Newsletter for a short - write-up: - <a - href="https://www.freebsdfoundation.org/news-and-events/newsletter/freebsd-foundation-update-october-2018/">https://www.freebsdfoundation.org/news-and-events/newsletter/freebsd-foundation-update-october-2018/</a></p> - - <p>One encountered problem stems from process handling.</p> - - <p>The standard process life cycle on UNIX-like systems looks - like this:</p> - - <ul> - <li>a process is created with fork(2)</li> - - <li>it can do regular work or execve(2) a new binary</li> - - <li>it exits, becoming a zombie</li> - - <li>the parent collects the exit code and removes the zombie</li> - </ul> - - <p> - There are other variations (e.g. vfork(2) can be used - instead of - fork).</p> - - <p>When you type 'ls' into your shell, it will typically - vfork a new process - which will then execve /bin/ls.</p> - - <p>All this is guarded with several global kernel locks, but - the granularity - can be significantly improved.</p> - - <p>A different problem stems from pipes.</p> - - <p>Pipes are used all the time, e.g. "du -s | sort -n" - creates a pipe whose - one endpoint is standard output for du and another is - standard input for sort.</p> - - <p>By default the pipe can hold up to 16KB before it gets - filled up.</p> - - <p>The kernel dedicates part of its virtual address space to - hold pipe buffers - and allocates/deallocates physical pages as pipes get - created/destroyed. - This induces TLB invalidation requests to other CPUs, - which causes an - unnecessary slowdown.</p> - - <p>An easy way out is to cache a certain number of buffers.</p> - - </body> - - <sponsor> - The FreeBSD Foundation - </sponsor> - - </project> - - <project cat='proj'> - <title>String functions on the amd64 architecture</title> - - <contact> - <person> - <name>Mateusz Guzik</name> - <email>mjg@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>Functions like memset, memmove and memcpy are very - frequently used by virtually - all programs. They can be optimized in various ways, but - FreeBSD uses very - rudimentary implementations using rep movsq/stosq. rep - prefix has high startup - latency which is overly expensive when dealing with small - sizes.</p> - - <p>Short term goal of this project is to implement faster - variants for the kernel - and import them into libc. The main speed up comes from - not using rep for small - sizes (< 256) and from aligning target buffers to 16 - bytes when rep is used. - On top of that runtime detection of the Enhanced REP - MOVSB/STOSB extention can - be used to only use rep movsb/stosb.</p> - - <p>Mid term goal extends userspace. SIMD extensions can be - used to make these functions - faster. They can't easily be used in the kernel: SIMD - registers are not saved on - transitions user<->kernel for performance reasons. - Thus any use would have to - take care of saving these registers, which can consume any - advantage from using them in - the first place. This is not a concern for userspace code.</p> - - <p>There is a BSD-licensed implementation in bionic: - <a - href="https://android.googlesource.com/platform/bionic/+/master/libc/arch-x86_64/string/">https://android.googlesource.com/platform/bionic/+/master/libc/arch-x86_64/string/</a></p> - - <p>which with some modifications can be used in libc later - on.</p> - - <p>See the Intel Optimization Manual for reference: - <a - href="https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf">https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf</a></p> - - </body> - - <sponsor> - The FreeBSD Foundation - </sponsor> - - </project> - - <project cat='proj'> - <title>32-bit compatibility and other ABI cleanups</title> - - <contact> - <person> - <name>Brooks Davis</name> - <email>brooks@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>As part of maintaining an external ABI (application binary - interface) - compatibility layer, I've been improving FreeBSD - infrastructure, - primarily the 32-bit compatibility layer. One of FreeBSD's - strengths is - that we can easily support many ABIs. This includes - support for a.out - format executables (vs the standard ELF), support for i386 - on amd64, the - Linux emulation layer, etc.</p> - - <p>This infrastructure has existed for decades and not every - design - decision has stood the test of time. Support has also been - incomplete - in a number of areas (e.g. network management under 32-bit - emulation).</p> - - <p>Committed improvements include:</p> - - <ul> - <li>Improved <tt>ioctl</tt> and <tt>sysctl</tt> support to - allow <tt>ifconfig</tt> and - <tt>netstat</tt> to work in 32-bit compat mode.</li> - <li>Migration from a model of translating <tt>ioctl</tt> - commands and data - structures at the kernel boundary to translating where the - commands - are processed. This is a correctness improvement (`ioctl` - commands - do not have meaning outside the specific file descriptor - in question) - and improves code reusability (my out-of-tree work will - soon include - a 64-bit compatibility layer.)</li> - <li>Simplifications of the generic ELF process execution path - by Ed - Maste, John Baldwin, and myself. A number of - simplifications including - minor speedups have been committed.</li> - </ul> - - <p> - Portions of this work were developed by SRI International - and the - University of Cambridge Computer Laboratory (Department of - Computer - Science and Technology) under DARPA/AFRL contract - FA8750-10-C-0237 - ("CTSRD"), as part of the DARPA CRASH research programme - and under DARPA - contract HR0011-18-C-0016 ("ECATS"), as part of the DARPA - SSITH research - programme.</p> - - <p>Work in progress includes cleanups to the APIs used by the - kernel when - creating processes and continued <tt>ioctl</tt> - improvements. Work is also - underway to generate the 32-bit system call list from the - "default" - list.</p> - - <p>The remaining <tt>ioctl</tt> commands handled in - <a - href="https://svnweb.FreeBSD.org/base/head/sys/compat/freebsd32/freebsd32_ioctl.c?view=log">sys/compat/freebsd32/freebsd32_ioctl.c</a> - need to be migrated to the point of implementation. Help - with the latter - would be appreciated.</p> - - </body> - - </project> - - <project cat='proj'> - <title>Save/Restore/Migration support in bhyve</title> - - <contact> - <person> - <name>Elena Mihailescu</name> - <email>elenamihailescu22@gmail.com</email> - </person> - <person> - <name>Darius Mihai</name> - <email>dariusmihaim@gmail.com</email> - </person> - <person> - <name>Sergiu Weisz</name> - <email>sergiu121@gmail.com</email> - </person> - <person> - <name>Mihai Carabas</name> - <email>mihai@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="https://github.com/FreeBSD-UPB/freebsd/tree/projects/bhyve_migration">Github repository for the save/restore and migration features</url> - <url href="https://github.com/FreeBSD-UPB/freebsd/wiki/Save-and-Restore-a-virtual-machine-using-bhyve">Github wiki - How to Save and Restore a bhyve guest</url> - <url href="https://github.com/FreeBSD-UPB/freebsd/wiki/Virtual-Machine-Migration-using-bhyve">Github wiki - How to Migrate a bhyve guest</url> - <url href="https://github.com/FreeBSD-UPB/freebsd/wiki/Suspend-Resume-test-matrix">Github wiki - Suspend/resume test matrix</url> - </links> - - <body> - <p>The Save/Restore feature is a facility to suspend and - resume guest - virtual images that has been added to the FreeBSD/amd64's - hypervisor, - bhyve. The bhyvectl tool is used to save the guest virtual - machine - into three files:</p> - - <ul> - <li>a file for the guest memory</li> - - <li>a file for state of each device / CPU state</li> - - <li>a file that has metadata that is used in the restore - process</li> - </ul> - - <p> - To suspend a bhyve guest, the bhyvectl tool must be run - with the <tt>--suspend - <state_file_name></tt> - option followed by the guest name.</p> - - <p>To restore a bhyve guest from a checkpoint, one simply has - to add the <tt>-r</tt> option - followed by the main state file (the same file that was - given to the <tt>--suspend</tt> - option for bhyvectl) when starting the VM.</p> - - <p>The Migration feature uses the Save/Restore implementation - to migrate a bhyve guest - from one FreeBSD host to another FreeBSD host. To migrate - a bhyve guest, - one needs to start an empty guest on the destination host - from a shared guest - image using the bhyve tool with the <tt>-R</tt> option - followed by the source host - IP and the port to listen to migration request. On the - source host, the - migration is started by executing the bhyvectl command - with the <tt>--migrate</tt> - option, followed by the destination host IP and the port - to send to the messages.</p> - - <p>New features added:</p> - - <ul> - <li>Create the socket connection between source and - destination hosts</li> - - <li>Migrate the guest state via sockets</li> - - <li>Separate the suspend/resume/migration code from the - bhyverun.c and bhyvectl.c and added two new files - for them: migration.c and migration.h</li> - - <li>Added save/restore state for xhci</li> - - <li>Added save/restore state for fbuf</li> - - <li>Fix vhpet restore state issues (timers related)</li> - - <li>Add partially support for suspending and resuming a Linux - guest</li> - </ul> - - <p>Future tasks:</p> - - <ul> - <li>Check if live migration can be implemented using the - FreeBSD's Copy-on-Write mechanism</li> - - <li>Add live migration support by using EPT (Intel)</li> - - <li>Add live migration support by using NPT (AMD)</li> - - <li>Add suspend/resume support for nvme</li> - - <li>Add suspend/resume support for virtio-console</li> - - <li>Add suspend/resume support for virtio-scsi</li> - - <li>Fix restore timers issues</li> - - <li>Fix suspending bhyve - threads issues</li> - - <li>Fix suspending bhyve - mutexes issues</li> - - <li>Add suspend/resume support for Windows guests</li> - </ul> - - </body> - - <sponsor> - Matthew Grooms - </sponsor> - - <sponsor> - iXsystems - </sponsor> - - </project> - - <project cat='proj'> - <title>Building FreeBSD on non-FreeBSD hosts</title> - - <contact> - <person> - <name>Alex Richardson</name> - <email>arichardson@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="https://wiki.FreeBSD.org/BuildingOnNonFreeBSD">Wiki</url> - <url href="https://github.com/arichardson/freebsd/tree/crossbuild-aug2018">GitHub project</url> - </links> - - <body> - <p>Currently FreeBSD can only be built on a FreeBSD host. - However, most free - CI tools only allow building on Linux or macOS and - therefore can not be used - for building the FreeBSD base system. It is sometimes - useful to - cross-build FreeBSD for a remote machine or an emulator - even if the build - machine is not running FreeBSD. - The goal of this project is to allow building FreeBSD on - both Linux and macOS hosts - and in the future it may be extended to allow compiling on - a Windows host. - This work originates from the CHERI project and was - motivated by multiple cases of - people wanting to try out CheriBSD but not being able to - compile it since they did - not have a FreeBSD system available for compiling. - Once completed this project will also allow developers to - contribute to FreeBSD - even if they don't have access to a FreeBSD build system.</p> - - <p>The current set of patches for this project can be found - on - <a - href="https://github.com/arichardson/freebsd/tree/crossbuild-aug2018">GitHub</a>. - With the current prototype it is possible to compile both - world and kernel for - architectures that use the clang compiler and for MIPS64, - which uses gcc. However, some options such as - LOCALES are - not supported yet and require further changes before the - bootstrap tools can be built - on Linux/macOS.</p> - - <p>Some changes required for building on non-FreeBSD have - already been merged to - HEAD but there are still a rather large number of changes - that need review.</p> - - <p>If you are interested in getting this into HEAD and would - like to help, please - try the current prototype and report any issues to - arichardson@FreeBSD.org. - If you can help with reviewing the changes please contact - arichardson@FreeBSD.org - to be added to any pending Phabricator reviews.</p> - - </body> - - </project> - - <project cat='proj'> - <title>ENA FreeBSD Driver Update</title> - - <contact> - <person> - <name>Michał Krawczyk</name> - <email>mk@semihalf.com</email> - </person> - </contact> - - <links> - <url href="https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README">ENA README</url> - </links> - - <body> - <p>ENA (Elastic Network Adapter) is the smart NIC which is - used in the virtualised - environment of Amazon Web Services (AWS). It supports - multiple queues and can handle up to 25 Gb/s, - depending on the instance type on which it is - used.</p> - - <p>Since last report, ENA versions v0.8.0 and v0.8.1 have - been released, which introduced - many bug fixes, new features, optimization, stability and - error recovery - improvements. The last is especially important on the AWS, - where the instances - have to be reliable as they may be running very sensitive - functions and the - down time of the VM should be reduced to minimum.</p> - - <p>The v0.8.0 and v0.8.1 release patches included:</p> - - <ul> - <li>Upgrade of the HAL to version v1.1.4.3</li> - - <li>Improvement to the reset routine - the driver is now - triggering reset from - more fault points and is passing the reset reason to the - device, which can - perform the reset adequately to the encountered error.</li> - - <li>Device statistics (like global Tx and Rx counters) are no - longer read directly from the device. - The only exception is Rx drops, which are still read using - the AENQ - descriptor.</li> - - <li>The RX Out Of Order completion feature was added, which - enabled to cleanup the - RX descriptors out of order by keeping trace of all free - descriptors.</li> - - <li>RX ring is now being monitored, to prevent the ring from - stalling.</li> - - <li>Error handling paths were reworked and fixed.</li> - - <li>Driver was covered with branch prediction statements, to - make the most - of this CPU feature in the hot paths.</li> - - <li>Fix handling of the DF flag in the IP packets.</li> - - <li>Add dynamic logging and reduce number of messages being - printed by the driver.</li> - - <li>MTU configuration now is being verified using the device - capabilities instead - of a constant value.</li> - - <li>Do not pass packet header length hint to the device, - because for the chained - mbufs it may be problematic to determine header length, if - the header is split - into multiple segments.</li> - </ul> - - </body> - - <sponsor> - Amazon.com Inc. - </sponsor> - - </project> - - <project cat='proj'> - <title>FreeBSD Graphics Team</title> - - <contact> - <person> - <name>FreeBSD Graphics Team</name> - <email>x11@FreeBSD.org</email> - </person> - <person> - <name>Niclas Zeising</name> - <email>zeising@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="https://github.com/FreeBSDDesktop">Project GitHub page</url> - </links> - - <body> - <p>The FreeBSD X11/Graphics team is responsible for the lower - levels of the FreeBSD - graphics stack. This includes graphics drivers, graphics - libraries such as the - MESA OpenGL implementation, the X.org xserver with related - libraries and - applications, and Wayland with related libraries and - applications.</p> - - <p>There have been a lot of changes since the last report. - The most important one - is the change of driver distribution and updates. On - FreeBSD 11.2 and later - modern graphics drivers using the Linux KPI subsystem are - found in ports. These - give much improved support for Intel and AMD graphics - hardware, however, they - are currently only available for amd64.</p> - - <p>The legacy drivers available in the FreeBSD base system - are also available in - the ports tree, since they cause issues with the new - drivers. They will remain - in tree for 11.2 and 12, but work is on-going to have them - removed for 13, - except for arm.</p> - - <p>The easiest way to install the new drivers is to install - graphics/drm-kmod which - will install the correct driver depending on your - architecture and FreeBSD - version.</p> - - <p>There have been changes to the ports as well. Most notably - is the changed - handling of OpenGL dependencies, which has moved to USES - instead of being - handled directly in bsd.port.mk. Other big infrastructure - changes is the move - from individual \*proto packages to xorgproto, and turning - that into a build - time dependency. Many thanks to portmgr for help with - exp-runs for these - changes.</p> - - <p>There have been updates to applications and libraries as - needed.</p> - - <p>On the project management side, there is ongoing work to - set up a more efficient - way of working, including bi-weekly conference calls to - discuss the current - works in progress. Notes from these conference calls will - be posted on the - mailing list.</p> - - <p>Looking forward, the current major work in progress is to - update the graphics - driver to be on par with Linux 4.17. The code is merged, - but patching and bug - fixing is ongoing.</p> - - <p>There is also work to port the VMware guest graphics - driver, vmwgfx, to FreeBSD - and to the Linux KPI, to get better graphics support in - VMware.</p> - - <p>Lastly, on the driver side is to get the new graphics - drivers to work on i386 as - well. Experimental support for this exists in the code - repository, but is not - yet merged to the FreeBSD ports tree.</p> - - <p>In userland, the biggest things happening is the update of - the input stack, - including libinput and supporting libraries.</p> - - <p>Work is also ongoing on updating MESA libraries.</p> - - <p>On the project management side, the most important tasks - is to continue to work - on the team, and how we work internally.</p> - - <p>We are also working on setting up a list of requirements - for testing, so that we - can be reasonably assured that updates won't cause - regressions.</p> - - <p>People who are interested in helping out can find us on - the x11@FreeBSD.org - mailing list, or on our Gitter chat: <a - href="https://gitter.im/FreeBSDDesktop/Lobby">https://gitter.im/FreeBSDDesktop/Lobby</a>. - We - are also available in #freebsd-xorg on EFNet.</p> - - <p>We also have a team area on GitHub where our work - repositories can be found: - <a - href="https://github.com/FreeBSDDesktop">https://github.com/FreeBSDDesktop</a></p> - - </body> - - </project> - - <project cat='proj'> - <title>ifuncs</title> - - <contact> - <person> - <name>Konstantin Belousov</name> - <email>kib@FreeBSD.org</email> - </person> - <person> - <name>Ed Maste</name> - <email>emaste@FreeBSD.org</email> - </person> - <person> - <name>Mark Johnston</name> - <email>markj@FreeBSD.org</email> - </person> - <person> - <name>Mateusz Guzik</name> - <email>mjg@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>An ifunc is a special construct in an ELF object, which - allows for - the selection of the implementation for the given symbol - at runtime, - when the ELF module gets the final relocations applied. - The selection - of which code to use is governed by the small piece of - user provided - code, attached to the symbol, the so called resolver - function. - Ifuncs provide a convenient way to select between - different - machine-specific implementations of the parts of the code, - without - the ugliness and unsafety of the alternative approach, - which is - runtime patching.</p> - - <p>Ifuncs require support both from the static linker ld(1), - and from the - runtime linker for the corresponding execution - environment. On - FreeBSD, with the switch from the ancient GPLv2 licensed - BFD-based - ld(1) to either in-tree LLD or external modern BFD ld, the - use of - ifuncs become possible. Runtime linkers for ifunc support - exists for - the following environments:</p> - - <ul> - <li>i386, amd64, and arm64 kernels</li> - - <li>usermode dynamic linker ld-elf.so.1 on i386 and amd64</li> - - <li>static binaries startup code for i386 and amd64</li> - </ul> - - <p> - The use of ifuncs were previously applied for optimization - of the - following areas of the amd64 kernel:</p> - - <ul> - <li>context switching code, instead of huge number of runtime - checks - (PTI vs non-PTI, PCID or not, is INVPCID instruction - supported for - PCID) now uses set of mode-specific routines, see - pmap_activate_sw(). Besides removing checks at runtime, it - also - makes the code much more cleanly structured and readable.</li> - - <li>TLB and cache flush implementation.</li> - - <li>memcpy/memmove, copyin/copyout variants selection for ERMS - and SMAP.</li> - - <li>FPU state save and restore, depending on the support for - AVX or not, - this is also used on i386.</li> - </ul> - - <p> - For amd64 userspace, we currently use ifunc for - optimization of the - architecture dependent TLS base set and get functions.</p> - - </body> - - <sponsor> - The FreeBSD Foundation - </sponsor> - - </project> - - <project cat='proj'> - <title>Intel Work on Core Enabling and Security</title> - - <contact> - <person> - <name>Ben Widawsky</name> - <email>bwidawsk@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>A new team has been formed within Intel to help with side - channel security - mitigations as well as core enabling. They are evaluating - work from all areas - except networking. The team is currently focusing on two - areas:</p> - - <ol><li>Power Management improvements</li> - <li>NVDIMM namespace support</li></ol> - - <p>The ultimate goal of the power management work is to get - runtime power - management to hit "opportunistic idle". What this means is - when devices are - idle, the OS will power them down, and when everything - goes idle certain SoCs - will allow you to hit very low power states across the - platform. FreeBSD - currently doesn't have any notion of runtime power - management, and many devices - don't properly implement suspend and resume. In addition, - some preliminary work - is in process as it was thought to help when eventually - enabling opportunistic - idle. That preliminary work has been happening and is now - up for review:</p> - - <ul> - <li><a - href="https://reviews.FreeBSD.org/D17675">https://reviews.FreeBSD.org/D17675</a></li> - - <li><a - href="https://reviews.FreeBSD.org/D17676">https://reviews.FreeBSD.org/D17676</a></li> - </ul> - - <p> - NVDIMM namespace support has also been put up for review. - ACPI spec defines - namespaces as a way of partitioning the device into - separate labels. The current - work will integrate with geom(4). How these are used is - application dependent. - This work is up for review as well: <a - href="https://reviews.FreeBSD.org/D17619">https://reviews.FreeBSD.org/D17619</a></p> - - <p>The team has additionally taken on smaller tasks like - porting turbostat(8), - working on git svn init scripts, some small modifications - to acpi tooling, and - an effort to create a port PMDK.</p> - - </body> - - </project> - - <project cat='proj'> - <title>LLVM 7.0 - Sanitizers support improvements / Static code analysis</title> - - <contact> - <person> - <name>David Carlier</name> - <email>devnexen@gmail.com</email> - </person> - </contact> - - <links> - <url href="http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html">Release notes</url> - </links> - - <body> - <p>In order to increase the FreeBSD tooling to uncover - code bugs in the userland, further compiler-rt components - support and static code analysis improvements had been - added - since the last 6.0 version.</p> - - <p>Starting with the sanitizers, Memory Sanitizer (for amd64) - mainly to - detect unitialized pointers. There is also a simple W^X - paging - requests detection available from most of sanitizers.</p> - - <p>Also libFuzzer support finally had been possible. - It allows code to be tested with random values from corpus - inputs. - Mutation and combination algorithms of those random inputs - can be overwritten. Can also be used in addition to ubsan, - asan, msan and so on.</p> - - <p>At last, the X-Ray instrumentation feature is also - supported. - It is mainly about performance profiling purposes for a - reasonable performance runtime cost.</p> - - <p>In the static code analysis department, reliable strlcpy - (unfortunately strlcat - did not get merged in due time for the release) wrong - usage - cases are now covered and W^X code detection tooling had - been added.</p> - - <p>At the moment, this 7.0 version is imported by Dimitry - Andric, within - its own git branch available only for FreeBSD after 12 - releases.</p> - - </body> - - </project> - - <project cat='proj'> - <title>Boot Loader</title> - - <contact> - <person> - <name>Warner Losh</name> - <email>imp@FreeBSD.org</email> - </person> - <person> - <name>Kyle Evans</name> - <email>kevans@FreeBSD.org</email> - </person> - <person> - <name>Toomas Soome</name> - <email>tsoome@Freebsd.org</email> - </person> - </contact> - - <body> - <p>The FreeBSD boot loader lives in src/stand (prior releases - had it in - sys/boot and lib/libstand). It covers all the code that - the project - provides that interacts with the hardware before the - kernel starts.</p> - - <p>The LUA interpreter added earlier in 2018 was made default - in 2018Q3. - Due to undiagnosed booting issues, the LUA interpreter has - been - disabled on sparc64 and all powerpc. The LUA interpreter - is scheduled - to replace the FORTH interpreter entirely in FreeBSD 13, - although the - FORTH interpreter will remain available as a build option - in FreeBSD - 12. The plans are not to remove the FORTH loader for about - a year - after 12.0 release, or approximately January 2020. - Platforms not - currently working with the LUA interpreter - have until that date to resolve the issues.</p> - - <p>At this point, the LUA scripts implement everything that - the FORTH scripts - did. Where there was ambiguity in the spec, or where the - FORTH scripts - were more forgiving than was strictly documented, every - effort has - been made to improve the documentation and follow the old - FORTH - behavior, or document the new behavior where the old - behavior was - clearly a bug.</p> - - <p>It's anticipated that no further changes to the FORTH - loader or the - FORTH scripts will happen. They are quite mature and - bullet proof at - this point and it's unlikely that an undiscovered bug will - need to be - fixed before retirement.</p> - - <p>Other work in progress includes Toomas Soome's port to - OpenIndiana. In - addition to porting, he's enhanced the code in a number of - ways (both - in the block layer, and UEFI). Many of his improvements - have been - committed to FreeBSD, though a few remain and hopefully - will be - entering the tree soon after the freeze lifts.</p> - - <p>UEFI booting has been greatly enhanced. There are still - some - machines that have issues with the default BootXXXX - variables or - something else in the environment that are being - investigated. We hope - to understand the problems well enough to provide a fix - for FreeBSD - 12.0.</p> - - <p>Ian Lepore has reworked the GELI support so that it is - architecture independent and can be - used on any architecture we support.</p> - - <p>There are also efforts underway to support booting signed - images, improved - crypto booting options, and implement Multiboot 2.0 - support.</p> - - </body> - - </project> - - <project cat='proj'> - <title>Usermode mapping of PCI BARs</title> - - <contact> - <person> - <name>Konstantin Belousov</name> - <email>kib@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>Modern PCI(e) devices typically define memory-mapped BARs - (Base Address Registers) to make a memory region available - to the device. - Each BAR - has a separate page-aligned boundary and memory region - associated with it. - This is enforced by the need - of hypervisors to provide the pass-through using VT-d, - which operates - with memory and has the granularity of one page for access - control. - As is, it - also means that the BARs have a suitable configuration for - providing - access to usermode, controlling access by the normal page - tables.</p> - - <p>Linux already gives a way for userspace mapping of BARs - using sysfs.</p> - - <p>Of course, if a userspace program has enough privileges, - it can read a BAR, - determine the physical address of the mapping as seen by - CPU, and use - mem(4) (aka /dev/mem) to mmap() that region of memory. - This is very cumbersome, and leaves many unresolved - issues. - For example, a BAR might be not activated, which would - require - involvement of the IOMMU on some architectures. Also this - rude approach - makes it very hard to create mappings with the correct - caching - attributes.</p> - - <p>The FreeBSD pci(4) driver was enhanced to support such - mappings, and pciconf(8) utility was extended to use the - new support. - See pci(4) - for PCIOCBARMMAP ioctl(2) request description for details, - and - pciconf(8) for the -D switch.</p> - - <p>TODO: automatically activate the BAR on mapping, this is - not done yet. - There is a problem with avoiding the resource conflicts on - possible future attachmens of the kernel driver.</p> - - </body> - - <sponsor> - The FreeBSD Foundation - </sponsor> - - <sponsor> - Mellanox Technologies - </sponsor> - - </project> - - <project cat='proj'> - <title>Device Mode USB</title> - - <contact> - <person> - <name>Edward Tomasz Napierala</name> - <email>trasz@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/usb-device-mode.html">Handbook chapter</url> - </links> - - <body> - <p>Many embedded boards include hardware which supports - device - side USB - the ability for the board to present itself to - another - system as a USB drive, network adapter, or a virtual - serial port. - The FreeBSD USB stack has supported this functionality for - quite some - time, but it has not been used to its fullest extent.</p> - - <p>The goal of this project was to fix that - to document the - functionality, possibly fix some bugs, and to make it easy - to use, automating it as much as possible.</p> - - <p>Starting with FreeBSD 12.0, this functionality is enabled - out of the box. This means you can connect your BeagleBone - Black's (using its USB client socket) or a Raspberry Pi 0 - (using the On-The-Go (OTG) port) to your laptop, and - you'll get a virtual - USB serial port, which serves as a system console, with - getty(8) - waiting for you to log in. This means you no longer need - to - look for a keyboard and a screen, or mess with the console - cables just to configure your system. You can also switch - it to provide network interface, or present itself as a - USB - drive - it's all documented in the FreeBSD Handbook.</p> - - </body> - - <sponsor> - The FreeBSD Foundation - </sponsor> - - </project> - - <project cat='proj'> - <title>Performance improvements</title> - - <contact> - <person> - <name>Matthew Macy</name> - <email>mmacy@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>FreeBSD 12 saw the introduction of a number of performance - improvements:</p> - - <ul> - <li>The introduction of the new synchronization primitive - epoch(9) to - replace the use of reader locks for providing existence - guarantees - for data structures.</li> - - <li>epoch(9) was used to provide an 85+% reduction in the - overhead of - pcb lookup in high core count systems.</li> - - <li>epoch(9) was used to provide an 85+% reduction in UDP send - overhead - on high core count systems. See the link for a bit more - detail: - <a - href="http://scalebsd.org/blog/2018/06/16/UDP-and-epoch-for-liveness-guarantees">http://scalebsd.org/blog/2018/06/16/UDP-and-epoch-for-liveness-guarantees</a></li> - <li>System call overhead is now half that of FreeBSD 11.</li> - - <li>UNIX sockets now scale near linearly (previously maxed out - at 3-4 threads).</li> - - <li>The NUMA work has lead to a 20x-80x improvement in the - scalability - of page fault handling.</li> - </ul> - - </body> - - </project> - - <project cat='arch'> - <title>Armada 38x FreeBSD support</title> - - <contact> - <person> - <name>Marcin Wojtas</name> - <email>mw@semihalf.com</email> - </person> - <person> - <name>Patryk Duda</name> - <email>pdk@semihalf.com</email> - </person> - <person> - <name>Rafał Kozik</name> - <email>rk@semihalf.com</email> - </person> - </contact> - - <links> - <url href="https://www.marvell.com/documents/egrkpyqzpoebxblyeept/">PRODUCT BRIEF</url> - </links> - - <body> - <p>The Marvell Armada 38x is a very poplular ARMv7-based dual - core SoC. - Thanks to the multiple low and high speed interfaces - the platform is used in a wide range of products, such - as Network-Attached Storage (NAS), Wi-Fi Access Point - (WAP) and others.</p> - - <p>Since last report, remaining Armada 38x support was - integrated to HEAD, which can now compile with the - armv7 - GENERIC config and use unmodified sys/gnu/dts device - trees. The details are as follows:</p> - - <ul> - <li>GENERIC config</li> - - <li>Introduce a vast rework of the sys/arm/mv directory for - arm and armv7 platforms.</li> - - <li>Enable PLATFORM support for Marvell ARMv7 SoCs, which can - now can boot with GENERIC kernel.</li> - - <li>Base on dynamic detection of SoC type and device tree - instead of using ifdefs - and enable more flexible environment for maintaining - Marvell platforms.</li> - - <li>sys/gnu/dts device trees</li> - - <li>Improve platform code and the drivers (e.g. CESA, PCIE, - GPIO) to properly work with original - Linux device trees.</li> - - <li>GPIO</li> - - <li>Add multiple fixes and improvements to the - sys/arm/mv/gpio.c</li> - - <li>Rework driver to properly integrate with HEAD GPIO - frameworks (main and gpioled)</li> - - <li>Enable support for both old and Linux GPIO device tree - bindings, so that multiple controllers - can be used.</li> - </ul> - - </body> - - <sponsor> - Stormshield - </sponsor> - - <sponsor> - Semihalf - </sponsor> - - </project> - - <project cat='arch'> - <title>PINE64-LTS Image</title> - - <contact> - <person> - <name>Emmanuel Vadot</name> - <email>manu@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>We now produce an image for the PINE64-LTS. - This image works on the PINE64-LTS and the Sopine with - Baseboard.</p> - - </body> - - </project> - - <project cat='arch'> - <title>PocketBeagle Support</title> - - <contact> - <person> - <name>Emmanuel Vadot</name> - <email>manu@FreeBSD.org</email> - </person> - <person> - <name>Tom Jones</name> - <email>thj@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="https://www.beagleboard.org/pocket">Pocket Beagle</url> - </links> - - <body> - <p>The Pocket Beagle is the latest member of the BeagleBoard - family. - Support for it was added and the Beaglebone image can be - used on it directly.</p> - - </body> - - </project> - - <project cat='arch'> - <title>Allwinner SoC Support</title> - - <contact> - <person> - <name>Emmanuel Vadot</name> - <email>manu@FreeBSD.org</email> - </person> - </contact> - - <body> - <ul> - <li>SPI driver added for A64 SoC</li> - - <li>Thermal driver added/fixed for A64/H3/H5 SoCs</li> - - <li>Lot of bugs where fixed in the mmc driver, stability - should be better</li> - - <li>New driver for AXXP803 which is the power chip companion - of the A64 SoC</li> - - <li>Add overlays to use another timer controller as the - default one in A64 if faulty - These overlay is enabled in the PINE64/LTS images by - default</li> - </ul> - - </body> - - </project> - - <project cat='arch'> - <title>ARMv6 and ARMv7 image now use EFI loader</title> - - <contact> - <person> - <name>Emmanuel Vadot</name> - <email>manu@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>Instead of using the ubldr version of the loader which - uses the U-Boot - API, all images now use loader.efi as their primary - FreeBSD loader. - This allow us to have a common boot path for all arm and - arm64 images.</p> - - </body> - - </project> - - <project cat='arch'> - <title>DTS Update</title> - - <contact> - <person> - <name>Emmanuel Vadot</name> - <email>manu@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>DTS files (Device Tree Sources) were updated to be on par - with Linux 4.18 for - the 12.0 release.</p> - - <p>The DTS are now compiled for some arm64 boards as the one - present in U-Boot are - now always up-to-date.</p> - - </body> - - </project> - - <project cat='arch'> - <title>RPI Firmware/DTB/U-Boot Update</title> - - <contact> - <person> - <name>Emmanuel Vadot</name> - <email>manu@FreeBSD.org</email> - </person> - <person> - <name>U-Boot mailing list</name> - <email>uboot@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>The RaspberryPi firmware loads the DTB from the FAT - partition based on - the model. U-Boot now uses this DTB and passes it to the - FreeBSD loader/kernel - instead of using the DTS embedded in U-Boot. - This allow the FreeBSD Kernel to use the RaspberryPi - Foundation provided DTB overlays to enable - HATs. - The overlays can be obtained by installing the - rpi-firmware package.</p> - - <p>A new U-Boot port for the W variant of the RPI0 was - committed as - u-boot-rpi-0-w. Some experiments started by Edward Tomasz - Napierala - (trasz@) have shown that we could possibly produce a - generic image - for all armv6 RPI (RPI-B, RPI0 and RPI0W).</p> - - </body> - - </project> - - <project cat='arch'> - <title>FreeBSD on PowerNV (ppc64)</title> - - <contact> - <person> - <name>Patryk Duda</name> - <email>pdk@semihalf.com</email> - </person> - <person> - <name>Wojciech Macek</name> - <email>wma@FreeBSD.org</email> - </person> - <person> - <name>Michal Stanek</name> - <email>mst@semihalf.com</email> - </person> - <person> - <name>Nathan Whitehorn</name> - <email>nwhitehorn@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>Semihalf is happy to announce that FreeBSD is now running - on IBM POWER8. This project is a continuation of - work done by Nathan Whitehorn who provided basic - support for a PowerNV emulator.</p> - - <p>The IBM POWER8 family of CPUs offers superior performance - compared to previous Power series. It provides - complete NUMA support with up to 192 cores in a - two socket system (up to 8 threads per core). All - IO communication is handled by integrated PCIe - interface equipped with multiple IOMMU engines.</p> - - <p>The support for POWER8 system running FreeBSD in - Non-Virtualized environment contains:</p> - - <ul> - <li>Generic driver for OPAL hypervisor</li> - - <li>kboot loader modifications to allow Little-Endian loader - to load a Big-Endian kernel ELF</li> - - <li>skiboot update for ELF-parser allowing it to understand - FreeBSD kernel file format</li> - - <li>Basic support for PowerNV architecture, including modes of - operation, MMU, interrupt controller</li> - - <li>SMP operation (tested with 128 CPU configuration)</li> - - <li>PHB subsystem driver, including IOMMU mapping for external - buses</li> - - <li>PCIe host controller driver</li> - - <li>USB-3.0 XHCI driver</li> - - <li>Reworked drivers to be Big-Endian compatible:</li> - - <li>Chelsio cxgbe(4) 10/25G network adapter</li> - - <li>NVMe SSD drive</li> - </ul> - - <p> - All work has been merged into HEAD and will be included in - FreeBSD 12.0-RELEASE.</p> - - <p>Sponsors: IBM, FreeBSD Foundation, QCM Technologies, - Semihalf, Limelight Networks.</p> - - <p>The project is kindly initiated and supported by Limelight - Networks (Kevin Bowling).</p> - - </body> - - </project> - - <project cat='arch'> - <title>FreeBSD on POWER9</title> - - <contact> - <person> - <name>Matthew Macy</name> - <email>mmacy@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>Once Justin Hibbits largely stabilized the powerpc64 port - on the POWER9 - based Talos II I decided to procure one. I've been slowly - working towards - taking powerpc64 to parity with amd64. I've been working - in an out of tree - GitHub project - in part to eliminate the need to continue - to support the 11 - year old in tree gcc4.</p> - - <p>Progress so far:</p> - - <ul> - <li>Adapted lock_delay to use POWER's SMT scheduling hints - rather than - using the yield hint from an older ISA</li> - - <li>Added ifunc support</li> - - <li>Ported the amd64 pmap so FreeBSD can use POWER9's new - radix tree - page tables. This will give us superpages mostly for free.</li> - - <li>Reduced the overhead of copyinout primitives for radix.</li> - - <li>Converted the copyinout primitives to ifuncs to switch - between the - old and the new at initialization time.</li> - - <li>Converted pmap to use ifuncs to eliminate the overhead of - kobj dispatch.</li> - - <li>Hot patch out trap handling paths only needed by the older - hashed page - table support.</li> - </ul> - - <p> - Work in Progress:</p> - - <ul> - <li>NMI semantics: NMIs need to be emulated by only soft - disabling interrupts, - disabling interrupts blocks all interrupts except machine - check exceptions - and system resets.</li> - - <li>Superpage support: Superpages work in the functional - simulator running SMT4 - but currently crash on real hardware due to incomplete - page walk cache / - TLB invalidation.</li> - - <li>Kernel minidump - with radix MMU enabled minidump support - was a fairly - straightforward port but time needs to be spent on test / - debug.</li> - - <li>EARLY_AP_STARTUP - preliminary patches exist, but this is - more work on !x86 - architectures due to IPI setup not being tied to the CPU - code.</li> - </ul> - - <p> - A list of the other items needed to achieve kernel feature - parity with a - (wishful) list of milestones can be found at: - <a - href="https://github.com/POWER9BSD/freebsd/projects/1">https://github.com/POWER9BSD/freebsd/projects/1</a></p> - - </body> - - </project> - - <project cat='arch'> - <title>FreeBSD on RISC-V</title> - - <contact> - <person> - <name>Ruslan Bukin</name> - <email>br@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>FreeBSD/RISC-V has been one of the actively supported - projects during the past year.</p> - - <p>On a compiler front we have upstreamed FreeBSD - OS-dependent bits for GNU toolchain. It was - updated to GCC 8.1 and Binutils 2.30. FreeBSD - packages are available.</p> - - <p>FreeBSD Testsuite and required dependencies were - successfully built for RISC-V and we did a test - run: 152 tests failed out of 5186, which - demonstrates a very good result for initial run - and reveals areas to work on.</p> - - <p>We have added support for compressed ISA extension to KDB - debugger and DTrace FBT provider enabling - C-compressed kernel and userland by default. The - output of disassembling instructions in KDB is - looking similar to objdump.</p> - - <p>QEMU has updated to latest privilege spec allowing us to - bring up FreeBSD on it. The emulation is quite - fast: it takes one second only to boot FreeBSD to - single-user mode in QEMU: <a - href="https://www.youtube.com/watch?v=FnWpRBaWF18">https://www.youtube.com/watch?v=FnWpRBaWF18</a></p> - - <p>Platform-Level Interrupt Controller (PLIC) driver was - added. Interrupt support was converted to INTRNG. - PLIC is used in QEMU for virtio network and block devices. - With these changes, a full FreeBSD distribution - can now be booted in QEMU.</p> - - <p>Network virtualization support (VIMAGE) was fixed and - enabled by default now.</p> - - <p>In order to support RocketChip and derivatives we had to - work on A(accessed), D(dirty) PTE (page table - entry) bits management. - We have successfully tested this on a lowRISC board and it - is booting to multiuser just fine. lowRISC UART - driver was added.</p> - - <p>Superuser-User-Modify (SUM) bit in status register is now - used: kernel can access userspace only within - certain functions that explicitly handle crossing - user/kernel boundary.</p> - - </body> - - </project> - - <project cat='ports'> - <title>KDE on FreeBSD</title> - - <contact> - <person> - <name>Adriaan de Groot</name> - <email>adridg@FreeBSD.org</email> - </person> - <person> - <name>Tobias C. Berner</name> - <email>tcberner@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="https://FreeBSD.kde.org/">KDE FreeBSD</url> - </links> - - <body> - <p>KDE FreeBSD is responsible for the ports of the Plasma5 - and KDE4 desktops, and - all associated applications. Further we also manage the - Qt4 and Qt5 ports, as - well as CMake.</p> - - <p>We also care for the FreeBSD builders for KDE's upstream - CI on build.kde.org.</p> - - <p>Since the last status report a lot of things have changed. - First and foremost, - the Plasma5 Desktop and the Qt5 based KDE Applications - have finally made their - way into the official ports tree after lingering for - multiple years in our - development repository.</p> - - <p>Secondly KDE4 has been marked deprecated and will be - removed at the end of the - year. With Qt4 following no later than the next year (due - to the exponentially - increasing burden of maintenance).</p> - - <p>On a more technical side, bsd.qt.mk has been replaced by - qt.mk and qt-dist.mk. - The porter's handbook is being updated (with thanks to - Tobias Kortkamp).</p> - - <p>Further we have been keeping CMake and Qt5 and almost - every other port under our - control up to date. SDDM has been updated to the - next-to-latest release with - backported security fixes.</p> - - <p>One big issue we have is www/qt5-webengine, which requires - too much time to keep - up to date, as the underlying chromium is in need of many - patches, which change - with every release. Another upcoming issue is the way in - which FreeBSD's libinput - lags behind. This blocks future updates to KDE Plasma as - well as Wayland - improvements. Thankfully x11@ is looking at this issue - already, so it should be - fixed soon -- for the meantime people who want to give the - latest KDE Plasma - Desktop a try can use the appropriate branch from our - GitHub.</p> - - <p>People who are willing to contribute can find us on - #kde-freebsd on freenode, - the kde@FreeBSD.org mailing list. Further, we accept - pull-requests and - contributions on github.com/freebsd/freebsd-ports-kde.</p> - - </body> - - </project> - - <project cat='ports'> - <title>Puppet</title> - - <contact> - <person> - <name>Puppet Team</name> - <email>puppet@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="https://puppetcommunity.slack.com/messages/C6CK0UGB1/">PuppetLab's FreeBSD slack channel</url> - <url href="https://www.bsdcan.org/2018/schedule/events/930.en.html">BSDCan 2018: IT automation with Puppet</url> - </links> - - <body> - <p>Since our last status report last year, the puppet@ team - regularly updated the - Puppet ports to catch on upstream releases. We have also - held a Puppet talk at - BSDCan.</p> - - <p>More recently, Puppet 6 was released, and a bunch of new - ports appeared in the - FreeBSD ports tree: sysutils/puppet6, - sysutils/puppetserver6, - databases/puppetdb6 being (obviously) the main ones. In - this update, the Puppet - language has not been heavily modified. As a consequence, - upgrading from Puppet - 5 to Puppet 6 is an easy task compared to the experience - you may have - encountered from previous major version bumps. If you are - still using Puppet 4, - we recommend to schedule an upgrade soon: Puppet 4 is - expected to be EOL by the - end of 2018.</p> - - <p>Because distributing Marionette Collective modules via - Puppet is more efficient - than using packages, the - sysutils/mcollective-\*-{agent,client} ports have - been - deprecated. Marionette Collective itself being phased out - by PuppetLabs, the - sysutils/mcollective port is expected to be deprecated at - some point in the - future, but we plan to keep it until an alternative is - available. This - alternative, called Choria, is in active development by - R.I.Pienaar the - original author of Marionette Collective. We are actively - working with him to - support FreeBSD out of the box, and will commit - sysutils/choria to the tree as - soon as it is considered a drop-in replacement for - Marionette Collective.</p> - - </body> - - </project> - - <project cat='ports'> - <title>scarab: CLI tool for Bugzilla-related workflows</title> - - <contact> - <person> - <name>Oleksandr Tymoshenko</name> - <email>gonzo@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="https://github.com/gonzoua/scarab">GitHub repo</url> - </links> - - <body> - <p>scarab is a CLI tool that makes some of Bugzilla - functionality - available from the command line. Normally users interact - with the - <a - href="https://bugs.FreeBSD.org/bugzilla/">bugtracker</a> - using a web browser - but for certain workflows, Web UI may be more of an - obstacle - than help requiring to perform more steps compared to CLI - tool.</p> - - <p>Bugzilla provides XML-RPC interfaces that can be used for - automation/integration and there are several CLI tools - like - <a href="https://github.com/williamh/pybugz">pybugz</a> - that can be used - with bugs.FreeBSD.org as-is. They are generic - one-size-fits-all - tools which mean they can do a lot of thing at the cost of - more complex CLI.</p> - - <p>scarab was created to be more specialized and less complex - with following - principles in mind:</p> - - <ul> - <li>Be an auxiliary tool, not a replacement for the web UI</li> - - <li>Move complexity to a configuration file, keep arguments as - simple as possible</li> - - <li>Optimize for most common/tedious tasks</li> - </ul> - - <p> - Based on my experience with Bugzilla following tasks were - identified as - candidates for inclusion in the first release of the tool:</p> - - <ul> - <li>Downloading attachment on host machine and copying it to - devbox</li> - - <li>Creating a file on the devbox and copying it to a host - machine to be attached through Web UI</li> - - <li>Creating PRs with common fields' values</li> - </ul> - - <p> - First two operations were implemented as <tt>files</tt>, - <tt>fetch</tt>, <tt>fetchall</tt>, <tt>attach</tt> - commands of the tool.</p> - - <p>The third operation was implemented by introducing PR - templates, set of - predefined field/value pairs, that can be combined - run-time to provide higher - flexibility. More information and usage examples can be - found in the - <a - href="https://github.com/gonzoua/scarab/blob/master/examples/scarabrc">config - file example</a></p> - - </body> - - </project> - - <project cat='doc'> - <title>Quarterly Reports</title> - - <contact> - <person> - <name>Edward Tomasz Napierała</name> - <email>trasz@FreeBSD.org</email> - </person> - <person> - <name>Mateusz Piotrowski</name> - <email>0mp@FreeBSD.org</email> - </person> - </contact> - - <body> - <p>The Quarterly Reports have been resurrected after almost a - year long hiatus. - The old workflow, which consisted of users submitting - XML-formatted entries, - which would then get hand-assembled into DocBook, was - replaced with a new - one, using Markdown instead. The XML submission form was - replaced with - GitHub Pull Requests. This should make submissions and - editing much easier - and user-friendly.</p> - - </body> - - </project> - - <project cat='doc'> - <title>Cleaning up the Wiki</title> - - <contact> - <person> - <name></name> - <email>wiki-admin@FreeBSD.org</email> - </person> - </contact> - - <links> - <url href="https://wiki.FreeBSD.org/WikiFixitGroup/">Wiki Fixit Group Website</url> - <url href="irc://freebsd-wiki@irc.freenode.net">IRC channel</url> - </links> - - <body> - <p>The FreeBSD Wiki used to be a scratch pad for the FreeBSD - developers to - organize projects, store notes and publish articles that - were about to be added - to the handbook. Recently, however, the FreeBSD wiki - started to attract more - and more people from the wider FreeBSD community, which - resulted in a change of - the character of the wiki.</p> - - <p>As a result we decided to discuss the future of the tools - we want to use for - documentation in FreeBSD (one of such discussions was held - during BSDCam 2018, - you may see some notes - <a - href="https://wiki.FreeBSD.org/DevSummit/201808/DeveloperTools">here</a>). - The general - conclusion is that wiki is a great tool for what it was - meant for: organizing - projects and notes in the community of developers. We - should not move all our - documentation (especially handbooks) to Wiki as the - quality and maintainability - would suffer. On the other hand, the current workflow of - submitting - documentation patches, which involves checking out the doc - tree and patching - XML files is not ideal for many end users. This is why we - are trying to approach the problem from various - directions:</p> - - <ol><li>The wiki is being cleaned up of old content. We are - trying to define a clear - hierarchy of subpages and categories to make navigating - the wiki easier.</li> - <li>Some articles from the wiki are going to be migrated to - either the doc tree - or manual pages.</li></ol> - - </body> - - </project> - - <project cat='third'> - <title>HardenedBSD 2018Q3 Update</title> - - <contact> - <person> - <name>Shawn Webb</name> - <email>shawn.webb@hardenedbsd.org</email> - </person> - </contact> - - <body> - <p>Our last report was - <a - href="https://www.FreeBSD.org/news/status/report-2017-04-2017-06.html#HardenedBSD">June - 2017</a>. - A lot has transpired since then. In this status report, we - will - attempt to briefly cover all the progress we've made, - including the - few commits that made it upstream to FreeBSD.</p> - - <p>On 01 Jul 2018, we switched back to - <a - href="https://hardenedbsd.org/article/shawn-webb/2018-04-30/hardenedbsd-switching-back-openssl">OpenSSL</a> - as the crypto library provider in base. We did this - because we lack - the resources and the documentation for properly - supporting LibreSSL - in base. We still maintain LibreSSL in base; however, - OpenSSL is - simply the default crypto library (aka, - <tt>WITHOUT_LIBRESSL</tt> is the - default). We look forward to building a development - community around - LibreSSL in HardenedBSD such that we can re-enable - LibreSSL by - default, providing enhanced security for our users through - the - rejection of software monocultures.</p> - - <p>Cross-DSO Control Flow Integrity (Cross-DSO CFI) is an - exploit - mitigation from llvm that provides forward-edge - protections across - shared library and application boundaries. With - HardenedBSD 12-STABLE, - we launched non-Cross-DSO CFI support in base. Meaning, - CFI is only - applied to applications and not shared libraries. Along - with - SafeStack, which provides backward-edge protections, - Cross-DSO CFI - requires both ASLR and W^X for effectiveness as they store - crucial - metadata needing protection. HardenedBSD expertly, - efficiently, and - robustly fulfill those requirements through its PaX ASLR - and PaX - NOEXEC implementations.</p> - - <p>Over the past two years, we have slowly worked on - Cross-DSO CFI - support in HardenedBSD. In mid-2018, we made enough - progress that we - could publish an alpha - <a - href="https://hardenedbsd.org/article/shawn-webb/2018-07-16/preliminary-call-testing-cross-dso-cfi">Call-For-Testing - (CFT)</a>. - We need to integrate the Cross-DSO CFI support with the - RTLD such that - function pointers resolved through - <tt>dlopen(3)</tt>/`dlsym(3)` work properly - with the cfi-icall scheme. We also need to perform - experimental - package builds, find breakages, and fix those breakages. - We hope to - officially debut Cross-DSO CFI in the latter half of 2019 - with the - possibility of pushing back to 2020. HardenedBSD remains - the first and - only enterprise operating system to use CFI across the - base set of - applications.</p> - - <p>On 20 Aug 2018, we launched a new tool called - <tt>hbsdcontrol(8)</tt> to - toggle exploit mitigations on a per-application basis. - <tt>hbsdcontrol(8)</tt> uses filesystem extended - attributes and is the - preferred method for exploit mitigation toggling for those - filesystem - that support extended attributes (UFS, ZFS). Our original - utility, - <tt>secadm</tt>, should be used with filesystems that do - not support extended - attributes (NFS).</p> - - <p>In <a - href="https://hardenedbsd.org/article/shawn-webb/2018-09-17/announcing-hardenedbsd-foundation">September - 2018</a>, - the HardenedBSD Foundation Corp became a 501(c)(3) - tax-exempt, - not-for-profit organization in the USA. This means that - donations by - US persons are eligible for tax deductions. The creation - of the - HardenedBSD Foundation will ensure that HardenedBSD - remains successful - long-term. We look forward to working with the BSD - community to - provide an open source, clean-room reimplementation of the - grsecurity - patchset based on publicly-available documentation.</p> - - <p>We assisted Kyle Evans with the new <tt>bectl(8)</tt> - utility, primarily - enhancing jail support and fixing regressions. We are - grateful for - Kyle Evans' assistance in landing the enhancements - upstream in FreeBSD - and his overall responsiveness and helpfulness.</p> - - <p>Relevant commits for the <tt>bectl(8)</tt> are:</p> - - <ul> - <li><a - href="https://svnweb.FreeBSD.org/base?view=revision&revision=339047">r339047</a></li> - - <li><a - href="https://svnweb.FreeBSD.org/base?view=revision&revision=338221">r338221</a></li> - - <li><a - href="https://svnweb.FreeBSD.org/base?view=revision&revision=337993">r337993</a></li> - - <li><a - href="https://svnweb.FreeBSD.org/base?view=revision&revision=337947">r337947</a></li> - </ul> - - <p> - We taught <tt>bhyve(8)</tt> how to live in a - <a href="https://reviews.FreeBSD.org/rS337023">jailed - environment</a>, allowing users to - jail the hypervisor. We hardened the virtual address space - of - <tt>bhyve(8)</tt> by using <a - href="https://reviews.FreeBSD.org/rS338511">guard - pages</a>. - This work made it upstream to FreeBSD. We are grateful to - those in - FreeBSD who provided insight to increase the quality and - efficiency - of our patches.</p> - - </body> - - </project> - -</report> |