Page MenuHomeFreeBSD
Files F106141454

D34521.diff
No OneTemporary
Actions

D34521.diff
View Options

diff --git a/website/content/en/status/_index.adoc b/website/content/en/status/_index.adoc
--- a/website/content/en/status/_index.adoc
+++ b/website/content/en/status/_index.adoc
@@ -5,7 +5,7 @@
= FreeBSD Status Reports
-== Next Quarterly Status Report submissions (October - December) due: December 30th, 2021
+== Next Quarterly Status Report submissions (January - March) due: March 31st, 2022
Submit your entries as Pull Requests from your fork of link:https://github.com/freebsd/freebsd-quarterly[FreeBSD Status Report GitHub repo] or submit them via e-mail to quarterly-submissions@FreeBSD.org, using the link:https://github.com/freebsd/freebsd-quarterly/blob/master/report-sample.adoc[report-sample.adoc template].
@@ -23,6 +23,7 @@
== 2021
+* link:report-2021-10-2021-12/[October, 2021 - December, 2021]
* link:report-2021-07-2021-09/[July, 2021 - September, 2021]
* link:report-2021-04-2021-06/[April, 2021 - June, 2021]
* link:report-2021-01-2021-03/[January, 2021 - March, 2021]
diff --git a/website/content/en/status/report-2021-10-2021-12/_index.adoc b/website/content/en/status/report-2021-10-2021-12/_index.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/_index.adoc
@@ -0,0 +1,131 @@
+---
+title: "FreeBSD Quarterly Status Report 4th Quarter 2021"
+sidenav: about
+---
+
+= Introduction
+:doctype: article
+:toc: macro
+:toclevels: 2
+:icons: font
+:!sectnums:
+:source-highlighter: rouge
+:experimental:
+:reports-path: content/en/status/report-2021-10-2021-12
+
+This report covers FreeBSD related projects for the period between October and December. It is the fourth of four planned reports for 2021, and contains 19 entries. Highlights include faster boot times, more LLDB work, a base OpenSSH update, and more wireless development.
+
+Yours, +
+Pau Amma, Daniel Ebdrup, John-Mark Gurney, and Joe Mingrone
+
+'''
+
+toc::[]
+
+'''
+
+[[FreeBSD-Team-Reports]]
+== FreeBSD Team Reports
+
+Entries from the various official and semi-official teams, as found in the link:../../administration/[Administration Page].
+
+include::{reports-path}/freebsd-foundation.adoc[]
+
+'''
+
+include::{reports-path}/portmgr.adoc[]
+
+'''
+
+include::{reports-path}/doceng.adoc[]
+
+'''
+
+include::{reports-path}/www.adoc[]
+
+'''
+
+[[projects]]
+== Projects
+
+Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects.
+
+
+include::{reports-path}/aslr.adoc[]
+
+'''
+
+include::{reports-path}/boot-performance.adoc[]
+
+'''
+
+include::{reports-path}/lldb.adoc[]
+
+'''
+
+include::{reports-path}/ls1027a.adoc[]
+
+'''
+
+include::{reports-path}/membarrier-rseq.adoc[]
+
+'''
+
+include::{reports-path}/openssh.adoc[]
+
+'''
+
+include::{reports-path}/vdso.adoc[]
+
+'''
+
+[[kernel]]
+== Kernel
+
+Updates to kernel subsystems/features, driver support, filesystems, and more.
+
+
+include::{reports-path}/avx-bug.adoc[]
+
+'''
+
+include::{reports-path}/ena.adoc[]
+
+'''
+
+include::{reports-path}/iwlwifi.adoc[]
+
+'''
+
+include::{reports-path}/ocf-wg.adoc[]
+
+'''
+
+
+[[ports]]
+== Ports
+
+Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves.
+
+include::{reports-path}/kde.adoc[]
+
+'''
+
+include::{reports-path}/office.adoc[]
+
+'''
+
+[[third-Party-Projects]]
+== Third-Party Projects
+
+Many projects build upon FreeBSD or incorporate components of FreeBSD into their project.
+As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report.
+The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions.
+
+include::{reports-path}/hellosystem.adoc[]
+
+'''
+
+include::{reports-path}/pot.adoc[]
+
+'''
diff --git a/website/content/en/status/report-2021-10-2021-12/aslr.adoc b/website/content/en/status/report-2021-10-2021-12/aslr.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/aslr.adoc
@@ -0,0 +1,29 @@
+=== Enable ASLR by default for 64-bit executables
+
+Contact: Dawid Gorecki <dgr@semihalf.com> +
+Contact: Marcin Wojtas <mw@semihalf.com>
+
+Address Space Layout Randomization (ASLR) is an exploit mitigation
+technique implemented in the majority of modern operating systems.
+It involves randomly positioning the base address of an executable
+and the position of libraries, heap, and stack, in a process's address
+space. Although over the years ASLR proved to not guarantee full OS
+security on its own, this mechanism can make exploitation more difficult.
+
+The Semihalf team made an effort to switch on the address map
+randomization for PIE (Position Independent Executables) & non-PIE 64-bit binaries.
+Once the link:https://cgit.freebsd.org/src/commit/?id=b014e0f15bc73d80e[patch] was merged to HEAD,
+the ASLR feature became enabled for all 64-bit architectures.
+
+Additionally, the mentioned change disabled
+link:https://www.freebsd.org/cgi/man.cgi?query=sbrk&sektion=2[SBRK],
+in order to allow utilization of the bss grow region for mappings.
+It has no effect without ASLR, so it was applied to all architectures.
+
+TODO:
+
+* Improve stackgap feature implementation.
+
+* MFC to stable/13 branch.
+
+Sponsor: Stormshield
diff --git a/website/content/en/status/report-2021-10-2021-12/avx-bug.adoc b/website/content/en/status/report-2021-10-2021-12/avx-bug.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/avx-bug.adoc
@@ -0,0 +1,30 @@
+=== The AVX bug on amd64
+
+Commit: gitref:73b357be92385cbb70ba19e7023a736af2c6b493[repository=src] URL: link:https://cgit.freebsd.org/src/commit/?id=73b357be92385cbb70ba19e7023a736af2c6b493[https://cgit.freebsd.org/src/commit/?id=73b357be92385cbb70ba19e7023a736af2c6b493]
+
+Contact: Konstantin Belousov <kib@FreeBSD.org>
+
+Some CPUs support the so called init optimization for XSAVE, but not all CPUs
+do. And when they do, 'according to complex internal microarchitectural
+conditions', the optimization might happen or not. Basically, this
+means that sometimes the CPU does not write all of the state on
+XSAVE and records in xstate_bv that it did not.
+
+On signal delivery, the OS provides the saved context interrupted by
+the signal to the signal handler. The context includes all CPU state
+available to userspace, including FPU registers (XSAVE area). Also,
+on return from the signal handler, context is restored, which
+allows the handler to modify the main program flow.
+When init optimization kicks in, the OS tries to hide init state
+optimization from the signal handler, by filling non-saved parts of
+the XSAVE area.
+
+This is where the problem happens. For states parts 0 (x87) and 1
+(SSE/XMM), Intel CPUs do not provide an enumeration of layout in CPUID,
+assuming that the OS knows about the regions anyway. The bug was that
+the amd64 kernel hardcoded a 32bit size for the XMM save area, effectively
+filling %XMM8-%XMM15 with garbage on signal return when init
+optimization kicked in, because only specified part of the SSE save
+area was copied from the canonical save area.
+
+Sponsor: The FreeBSD Foundation
diff --git a/website/content/en/status/report-2021-10-2021-12/boot-performance.adoc b/website/content/en/status/report-2021-10-2021-12/boot-performance.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/boot-performance.adoc
@@ -0,0 +1,33 @@
+=== Boot Performance Improvements
+
+Links: +
+link:https://wiki.freebsd.org/BootTime[Wiki page] URL: link:https://wiki.freebsd.org/BootTime[https://wiki.freebsd.org/BootTime] +
+link:https://www.daemonology.net/blog/2021-08-12-EC2-boot-time-benchmarking.html[OS boot time comparison] URL: link:https://www.daemonology.net/blog/2021-08-12-EC2-boot-time-benchmarking.html[https://www.daemonology.net/blog/2021-08-12-EC2-boot-time-benchmarking.html]
+
+Contact: Colin Percival <cperciva@FreeBSD.org>
+
+Colin Percival is coordinating an effort to speed up the FreeBSD boot process.
+For benchmarking purposes, he is primarily using an EC2 c5.xlarge instance as a
+reference platform and is measuring the time between when the virtual machine
+enters the EC2 "running" state and when it is possible to SSH into the instance.
+
+This work started in 2017, and as of the end of September 2021 the FreeBSD boot
+time was reduced from approximately 30 seconds to approximately 15 seconds.
+
+During 2021Q4, further improvements have shaved more time off the boot process,
+taking it down to roughly 10 seconds. A further 4 seconds of improvements are
+in process.
+
+In addition, the userland boot process is now being profiled using TSLOG,
+making it possible to see flamecharts of the entire boot process; and the
+ec2-boot-bench tool is now able to generate MP4 videos of the boot process
+by taking snapshots of the EC2 VGA console.
+
+Issues are listed on the wiki page as they are identified; the wiki page also
+has instructions for performing profiling. Users are encouraged to profile
+the boot process on their own systems, in case they experience delays which
+don't show up on the system Colin is using for testing.
+
+This work is supported by Colin's FreeBSD/EC2 Patreon.
+
+Sponsor: https://www.patreon.com/cperciva
diff --git a/website/content/en/status/report-2021-10-2021-12/doceng.adoc b/website/content/en/status/report-2021-10-2021-12/doceng.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/doceng.adoc
@@ -0,0 +1,39 @@
+////
+Quarter: 4th quarter of 2021
+Prepared by: dbaio
+Reviewed by: carlavilla, bcr
+Last edit: $Date: 2022-01-05 20:07:39 -0300 (Wed, 05 Jan 2022) $
+Version: $Id: doceng-2021-4th-quarter-status-report.adoc 208 2022-01-05 23:07:39Z dbaio $
+////
+
+=== Documentation Engineering Team
+
+Links: +
+link:https://www.freebsd.org/docproj/[FreeBSD Documentation Project] URL: link:https://www.freebsd.org/docproj/[https://www.freebsd.org/docproj/] +
+link:https://docs.freebsd.org/en/books/fdp-primer/[FreeBSD Documentation Project Primer for New Contributors] URL: link:https://docs.freebsd.org/en/books/fdp-primer/[https://docs.freebsd.org/en/books/fdp-primer/] +
+link:https://www.freebsd.org/administration/#t-doceng[Documentation Engineering Team] URL: link:https://www.freebsd.org/administration/#t-doceng[https://www.freebsd.org/administration/#t-doceng]
+
+Contact: FreeBSD Doceng Team <doceng@FreeBSD.org>
+
+The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see link:https://www.freebsd.org/internal/doceng/[FreeBSD Doceng Team Charter].
+
+No new documentation commit bit was granted during the last quarter, and only one commit bit was safe kept.
+
+Several tasks were completed related to the doc tree during the last quarter:
+
+* A COPYRIGHT file was added in the root directory of the doc repository. The license was also updated to reflect the current toolchain the project is using now.
+
+* Cleanup of Mailman information in the doc tree. Following mailing lists migration from Mailman to Mlmmj, very old mailing lists were removed; most of the work was made on English documents.
+
+* Tag FreeBSD docset for 12.3-RELEASE.
+
+* Update all ports/packages misc/freebsd-doc-*.
+
+* Move articles/contributors/contrib-* files to the doc shared directory.
+
+* Add option in documentation Makefile to archive/compress Documentation/HTML offline files, a necessary step before updating https://download.freebsd.org/ftp/. This was after a discussion with clusteradm@ to update the offline assets (HTML/PDF).
+
+* Add experimental support for EPUB output (books/articles).
+
+* Talking with clusteradm@ to improve the performance of https://www.freebsd.org and https://docs.freebsd.org.
+
diff --git a/website/content/en/status/report-2021-10-2021-12/ena.adoc b/website/content/en/status/report-2021-10-2021-12/ena.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/ena.adoc
@@ -0,0 +1,26 @@
+=== ENA FreeBSD Driver Update
+
+Links: +
+link:https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README[ENA README] URL: link:https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README[https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README]
+
+Contact: Michal Krawczyk <mk@semihalf.com> +
+Contact: Dawid Gorecki <dgr@semihalf.com> +
+Contact: Marcin Wojtas <mw@semihalf.com>
+
+ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS).
+The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used.
+
+Completed since the last update:
+
+* Add IPv6 layer 4 checksum offload support to the driver
+* Add NUMA awareness to the driver when the RSS kernel option is enabled
+* Rework validation of the Tx request ID
+* Change lifetime of the driver's timer service
+* Avoid reset triggering when the device is unresponsive
+
+Work in progress:
+
+* Prototype the driver port to the iflib framework
+* Tests of the incoming ENA driver release (v2.5.0)
+
+Sponsor: Amazon.com Inc
diff --git a/website/content/en/status/report-2021-10-2021-12/freebsd-foundation.adoc b/website/content/en/status/report-2021-10-2021-12/freebsd-foundation.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/freebsd-foundation.adoc
@@ -0,0 +1,151 @@
+=== FreeBSD Foundation
+
+Links: +
+link:https://www.FreeBSDfoundation.org[FreeBSD Foundation] URL: link:https://www.FreeBSDfoundation.org[https://www.FreeBSDFoundation.org] +
+link:https://freebsdfoundation.org/blog/technology-roadmap/[Technology Roadmap] URL: link:https://freebsdfoundation.org/blog/technology-roadmap/[https://FreeBSDFoundation.org/blog/technology-roadmap/] +
+link:https://www.FreeBSDfoundation.org/donate/[Donate] URL: link:https://www.FreeBSDfoundation.org/donate/[https://www.FreeBSDFoundation.org/donate/] +
+link:https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/[Foundation Partnership Program] URL: link:https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program[https://www.FreeBSDFoundation.org/FreeBSD-foundation-partnership-program] +
+link:https://www.FreeBSDfoundation.org/journal/[FreeBSD Journal] URL: link:https://www.FreeBSDfoundation.org/journal/[https://www.FreeBSDFoundation.org/journal/] +
+link:https://www.FreeBSDfoundation.org/news-and-events/[Foundation News and Events] URL: link:https://www.FreeBSDfoundation.org/news-and-events/[https://www.FreeBSDFoundation.org/news-and-events/] +
+
+Contact: Deb Goodkin <deb@FreeBSDFoundation.org>
+
+The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to
+supporting and promoting the FreeBSD Project and community worldwide. Donations
+from individuals and corporations are used to fund and manage software
+development projects, conferences, and developer summits. We also provide travel
+grants to FreeBSD contributors, purchase and support hardware to improve and
+maintain FreeBSD infrastructure, and provide resources to improve security,
+quality assurance, and release engineering efforts. We publish marketing
+material to promote, educate, and advocate for the FreeBSD Project, facilitate
+collaboration between commercial vendors and FreeBSD developers, and finally,
+represent the FreeBSD Project in executing contracts, license agreements, and
+other legal arrangements that require a recognized legal entity.
+
+Here are some highlights of what we did to help FreeBSD last quarter:
+
+==== Fundraising Efforts
+
+We did it! We met our 2021 fundraising goal by raising $1,281,437!! On behalf
+of the Foundation, I want to thank you for your financial support last year,
+that will help us continue and increase our support for FreeBSD in 2022. In
+addition, folks are already sending us their 2022 contributions, which is
+incredibly heartwarming! We’ll start updating the fundraising meter for 2022
+by the end of January.
+
+In this Quarterly Status report you’ll read about many of the areas we funded
+in Q4 to improve FreeBSD and advocate for the Project (the two main areas we
+spend money on). Check out reports on the externally funded projects like LLDB
+support, Raid-Z Expansion, WireGuard, and wifi, as well as, internally supported
+work like improved security, tier-1 architecture support, and providing online
+opportunities to connect and educate the community.
+
+If you want to help us continue our efforts, please consider making a donation
+towards our 2022 fundraising campaign! https://www.FreeBSDFoundation.org/donate/.
+
+We also have a Partnership Program for larger commercial donors. You can read about
+it at https://www.FreeBSDFoundation.org/FreeBSD-foundation-partnership-program/.
+
+==== OS Improvements
+
+During the fourth quarter, Foundation staff and grant recipients committed 472
+src tree changes, 98 ports tree changes, and 11 doc tree changes. This
+represents 41%, 41%, and 13% of src, ports, and doc commits identifying a
+sponsor.
+
+You can read about Foundation-sponsored projects in individual quarterly report
+entries:
+
+- The AVX bug on amd64
+- Crypto changes for WireGurard
+- Intel Wireless driver support
+- LLDB Debugger Improvements
+- Base System OpenSSH Update
+- sched_getcpu(2), membarrier(2), and rseq(2) syscalls
+- VDSO on amd64
+
+Here is a small sample of other base system improvements from Foundation
+developers this quarter that do not have separate report entries.
+
+===== kern.proc.pathname canonical hard link
+
+Some programs adjust their behavior depending on which name was used for
+execution. For these programs, it is often important to have a consistent name
+in argv[0], sysctl kern.proc.pathname, auxv AT_EXECPATH, and any procfs file
+symlink. Before this work, all listed kernel interfaces tried to calculate some
+name for the text vnode and returned the result. If the executed binary has
+more than one hardlink, the returned names were arbitrarily chosen from the
+list of valid names for the file. After work completed this quarter by Foundation
+developer Konstantin Belousov, the system now holds the parent directory and the
+name of the text file for the running image. This is used to reconstruct the
+correct name of the text file when requested.
+
+===== swapon/swapoff, file swapping
+
+After work to fix asserts for character device vnode locking, there was a report
+that swap on file code broke the VFS locking protocol. Some other regressions
+in the swap on file were also identified. For instance, on shutdown,
+filesystems were unmounted before swapoff, which makes swapoff panic on page-in.
+These bugs were fixed and a link:https://www.freebsd.org/cgi/man.cgi?query=swapoff&apropos=0&sektion=2&manpath=FreeBSD+14.0-current&arch=default&format=html[swapoff(2)] feature was added to avoid some very
+conservative estimations for protection against memory and swap space shortages.
+
+===== fcntl(F_KINFO)
+
+Application developers often request an interface to return the file path for an
+open file descriptor. Our only useful facility for this was kern.proc.filedesc
+sysctl, which is somewhat usable, but incurs too high of an overhead when a
+process has many open files. A fcntl(F_KINFO) interface was added, which returns
+a struct kinfo_file just for the specified file descriptor. Among other useful
+data, kinfo_file provides the calculated path, when available.
+
+==== Continuous Integration and Quality Assurance
+
+The Foundation provides a full-time staff member and funds projects to improve
+continuous integration, automated testing, and overall quality assurance efforts
+for the FreeBSD project.
+
+==== Supporting FreeBSD Infrastructure
+
+The Foundation provides hardware and support for the Project. In the fourth
+quarter of 2021, we began searching for a new Australian mirror server. At the
+time of writing, the server is purchased, but with delays obtaining components
+and shipping, it may not be active until the second or third quarter of 2022.
+Better and faster access to our sites for the Australian FreeBSD community is
+coming.
+
+==== FreeBSD Advocacy and Education
+
+Much of our effort is dedicated to Project advocacy. This may involve highlighting interesting FreeBSD work, producing literature, attending events, or giving presentations. The goal of the literature we produce is to teach people FreeBSD basics and help make their path to adoption or contribution easier. Other than attending and presenting at events, we encourage and help community members run their own FreeBSD events, give presentations, or staff FreeBSD tables.
+
+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, working together on projects, and facilitating 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. We are continuing to attend virtual events and held a virtual vendor summit this past November.
+
+Check out some of the advocacy and education work we did last quarter:
+
+* Promoted and participated as a media sponsor for link:https://2021.allthingsopen.org/[ALL Things Open 2021]
+* Committed to being a Media Sponsor for link:https://www.socallinuxexpo.org/scale/19x[SCALE 19x]
+* Committed to hosting a link:https://stands.fosdem.org/stands/freebsd_project/[stand at FOSDEM 2022]
+* Sent out the link:https://freebsdfoundation.org/news-and-events/newsletter/freebsd-foundation-fall-2021-update/[Fall 2021 Newsletter]
+* Held a link:https://www.youtube.com/watch?v=BYTNpuinaPU[FreeBSD Friday talk: The Writing Scholar's Guide to FreeBSD], (link:https://www.coreystephan.com/freebsd-friday/[text equivalent])
+* Gave a Foundation talk at link:http://www.semibug.org/[Semi-Bug], November 16, 2021
+* Gave Foundation and FreeBSD talks at Seagate OSPO, December 9, 2021
+* Helped organize the 2 day link:https://wiki.freebsd.org/DevSummit/202111[FreeBSD Virtual Vendor Summit, November 18-19, 2021]. Videos can be found on the link:https://www.youtube.com/c/FreeBSDProject/videos[Project’s Youtube Channel]
+* New blog and video posts:
+** link:https://freebsdfoundation.org/news-and-events/newsletter/freebsd-foundation-fall-2021-update/[FreeBSD Foundation Fall 2021 Update]
+** link:https://freebsdfoundation.org/blog/2021-in-review-advocacy/[2021 in Review: Advocacy]
+** link:https://freebsdfoundation.org/blog/2021-in-review-infrastructure-support/[2021 in Review: Infrastructure Support]
+** link:https://freebsdfoundation.org/blog/2021-in-review-software-development/[2021 in Review: Software Development]
+** link:https://freebsdfoundation.org/blog/open-source-summit-2021-conference-recap/[Open Source Summit 2021 Conference Recap]
+* New How-To Guide: link:https://freebsdfoundation.org/freebsd-project/resources/freebsd-introduction/[Introduction to FreeBSD]
+
+We help educate the world about FreeBSD by publishing the professionally produced link:https://freebsdfoundation.org/our-work/journal/[FreeBSD Journal]. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues at https://www.FreeBSDfoundation.org/journal/.
+
+You can find out more about events we attended and upcoming events at https://www.FreeBSDfoundation.org/news-and-events/.
+
+==== Legal/FreeBSD IP
+
+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.
+
+Go to link:https://www.FreeBSDfoundation.org[https://www.FreeBSDFoundation.org]
+to find more about how we support FreeBSD and how we can help you!
diff --git a/website/content/en/status/report-2021-10-2021-12/hellosystem.adoc b/website/content/en/status/report-2021-10-2021-12/hellosystem.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/hellosystem.adoc
@@ -0,0 +1,27 @@
+=== helloSystem
+
+Links: +
+link:https://hellosystem.github.io/docs/[Documentation] URL: link:https://hellosystem.github.io/[https://hellosystem.github.io/]
+
+Contact: Simon Peter <probono@puredarwin.org> +
+Contact: `\#helloSystem` on `irc.libera.chat`, mirrored to link:https://matrix.to/#/%23helloSystem:matrix.org?via=matrix.org[`#helloSystem:matrix.org` on Matrix]
+
+==== What is helloSystem?
+
+helloSystem is FreeBSD preconfigured as a desktop operating system with a focus on simplicity, elegance, and usability.
+Its design follows the “Less, but better” philosophy.
+
+==== Q4 2021 Status
+
+* Version 0.7.0 of helloSystem has been published including many contributed features and bugfixes
+** helloSystem is now based on FreeBSD 13.0-RELEASE
+** Completely reworked Live ISO architecture, resulting in 1/3rd boot time and under 800 MB size (fits a CD-ROM)
+** Developer Tools are now a separate download
+** Disk Images are increasingly used throughout the system, such as for application distribution and Linuxulator userland deployment
+** Many new features and GUI utilities to make the desktop more usable for "mere mortals" without the need for a terminal
+
+Installable Live ISO images and a full changelog are available at https://github.com/helloSystem/ISO/releases/tag/r0.7.0
+
+==== Contributing
+
+link:https://github.com/helloSystem/hello/blob/master/CONTRIBUTING.md[The project appreciates contributions in various areas].
diff --git a/website/content/en/status/report-2021-10-2021-12/iwlwifi.adoc b/website/content/en/status/report-2021-10-2021-12/iwlwifi.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/iwlwifi.adoc
@@ -0,0 +1,23 @@
+=== Intel Wireless driver support
+
+Links: +
+link:https://wiki.freebsd.org/WiFi/Iwlwifi[iwlwifi status FreeBSD wiki page] URL: link:https://wiki.freebsd.org/WiFi/Iwlwifi[https://wiki.freebsd.org/WiFi/Iwlwifi]
+
+Contact: Bjoern A. Zeeb <bz@FreeBSD.ORG>
+
+The Intel Wireless driver update project aims to bring support for newer chipsets along with mac80211 LinuxKPI compat code.
+The dual-licensed Intel driver code was ported in the past for the iwm(4) native driver; using the LinuxKPI compat framework allows us to use the driver directly, with only very minor modifications that we hope will be incorporated into the original driver.
+
+During December the driver, firmware, and all remaining LinuxKPI compatibility code were committed to FreeBSD main (HEAD) and merged to the stable/13 branch.
+Further fixes, updates, and improvements will go directly into FreeBSD, meaning the need to apply snapshots is gone and changes can be distributed more timely.
+
+During the last months we tried to ensure that the latest AX210 chipsets are supported.
+The compat code was restructured both to be able to better trace and debug the mac80211 compatibility layer, but also to keep the net80211 and mac80211 state machines for stations better in sync.
+
+While we keep updating the driver and all the compat code needed for that, the focus remains on stability and adding support for newer 802.11 standards.
+The driver is still set to 11a/b/g-only and 11n will be next before we look at 11ac.
+
+With the code in FreeBSD git we anticipate broader testing and with that also some fallout.
+For the latest state of the development, please follow the referenced wiki page and the freebsd-wireless mailing list.
+
+Sponsor: The FreeBSD Foundation
diff --git a/website/content/en/status/report-2021-10-2021-12/kde.adoc b/website/content/en/status/report-2021-10-2021-12/kde.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/kde.adoc
@@ -0,0 +1,38 @@
+=== KDE on FreeBSD
+
+Links: +
+link:https://freebsd.kde.org/[KDE FreeBSD] URL: link:https://freebsd.kde.org/[https://freebsd.kde.org/] +
+link:https://community.kde.org/FreeBSD[KDE Community FreeBSD] URL: link:https://community.kde.org/FreeBSD[https://community.kde.org/FreeBSD]
+
+Contact: Adriaan de Groot <kde@FreeBSD.org>
+
+The KDE on FreeBSD project aims to package the software from the KDE Community, along with dependencies and related software, for the FreeBSD ports tree.
+That includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine.
+
+The KDE team (kde@) is part of desktop@ and x11@ as well, building the software stack to make FreeBSD beautiful and usable as a daily-driver graphics-based desktop machine.
+
+
+* Just two CMake updates this quarter, ending up with CMake 3.22.1. Some more patches have landed upstream, and CMake is soon to switch to `share/man` for manpages on FreeBSD. When it does, there will be plenty of `pkg-plist` churn.
+* Monthly releases of KDE Frameworks, KDE Plasma, and KDE Gear kept the exp-runs going. kde@ would like to thank Antoine for overseeing our many exp-run requests. We are now at KDE Frameworks 5.89 (latest release as of December 2021), link:https://kde.org/announcements/plasma/5/5.23.4/[KDE Plasma Desktop 5.23.4] and link:https://kde.org/announcements/gear/21.12.0/[KDE Gear 21.12].
+* Qt 5 is not receiving any open source updates from the Qt Company, but the KDE Community maintains its own set of patches that backport many fixes from Qt 6. Work is underway to import the KDE patch collection.
+* Qt 6 remains tantalizingly close. There hasn't been real progress on the crash-on-exit problem, though.
+* *deskutils/kalendar* is a relatively new port that uses KDE technologies for a desktop (appointments) calendar.
+* *deskutils/latte-dock*, an alternative launcher for KDE Plasma (and other environments) was updated to each of its bugfix releases.
+* *devel/qbs* and *devel/qtcreator* were updated. Qbs (or "Qt Build System") is a declarative build system styled along the lines of declarative QML programs. (Note that Qbs is not used by Qt itself).
+* *graphics/digikam* was updated to the latest release and now supports both ImageMagick 6 and ImageMagick 7. Speaking of which, a new `USES=magick` was introduced to simplify ports that depend in ImageMagick.
+* *graphics/ksnip*, one of several screenshot-applications for KDE Plasma (and other environments) had a lots-of-bugfixes update.
+* *graphics/skanpage* is a new port that scans multiple pages and produces a PDF of the whole.
+* *multimedia/qt5-multimedia* now ignores gstreamer-gl (rather than implicitly building with it as a dependency if it is installed a build time).
+* *net-im/ruqola* is a Rocket Chat client, updated to the latest release.
+* *security/qtkeychain* has a new release.
+
+Elsewhere in the software stack, kde@ also maintains ports that support the desktop in general. Some highlights are:
+
+* *devel/libphonenumber* keeps chasing changes to the world's phone numbers (the FreeBSD foundation can be reached at +1.720.207.5142).
+* *graphics/poppler* updated this much-used PDF-rendering library.
+* *multimedia/pipewire*, the audio-and-video successor to pulseaudio, was updated and now supports SSL as well.
+* *net/py-pytradfri* got several updates so you can control your lights from FreeBSD.
+* *print/freetype2* was updated to the latest release; relatedly, there was am update to *x11-toolkits/libXft*.
+* *print/harfbuzz*, the text-shaping library, was updated for more font type support.
+* *sysutils/bsdisks* is an implementation of DBus interfaces for examining disks (drives, partitions, etc.). It is also used for removable-disk notifications.
+* *x11-themes/adwaita-qt*, which connects the adwaita theme engine to Qt-based applications, was updated.
diff --git a/website/content/en/status/report-2021-10-2021-12/lldb.adoc b/website/content/en/status/report-2021-10-2021-12/lldb.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/lldb.adoc
@@ -0,0 +1,40 @@
+=== LLDB Debugger Improvements
+
+Links: +
+link:https://www.moritz.systems/blog/freebsd-kgdb-support-in-lldb/[Moritz Systems Project Description] URL: link:https://www.moritz.systems/blog/freebsd-kgdb-support-in-lldb/[https://www.moritz.systems/blog/freebsd-kgdb-support-in-lldb/] +
+link:https://www.moritz.systems/blog/lldb-serial-port-communication-support/[Progress Report 3] URL: link:https://www.moritz.systems/blog/lldb-serial-port-communication-support/[https://www.moritz.systems/blog/lldb-serial-port-communication-support/] +
+link:https://www.moritz.systems/blog/lldb-freebsd-kernel-core-dump-support/[Progress Report 4] URL: link:https://www.moritz.systems/blog/lldb-freebsd-kernel-core-dump-support/[https://www.moritz.systems/blog/lldb-freebsd-kernel-core-dump-support/] +
+link:https://github.com/moritz-systems/llvm-project[LLVM Git Repository] URL: link:https://github.com/moritz-systems/llvm-project[https://github.com/moritz-systems/llvm-project] +
+link:https://github.com/moritz-systems/libfbsdvmcore[libfbsdvmcore Git Repository] URL: link:https://github.com/moritz-systems/libfbsdvmcore[https://github.com/moritz-systems/libfbsdvmcore]
+
+Contact: Kamil Rytarowski <kamil@moritz.systems> +
+Contact: Michał Górny <mgorny@moritz.systems>
+
+According to the upstream description, "LLDB is a next generation,
+high-performance debugger. It is built as a set of reusable components which
+highly leverage existing libraries in the larger LLVM Project, such as the
+Clang expression parser and LLVM disassembler."
+
+FreeBSD includes LLDB in the base system. At present, it has some limitations
+compared to the GNU GDB debugger, and does not yet provide a complete
+replacement. This project spans from July 2021 to January 2022 and aims to
+make LLDB suitable for debugging FreeBSD kernels.
+
+The earlier part of the project was focused on improving compatibility between
+LLDB and other servers implementing the GDB Remote Protocol. This was followed
+by implementing a fully-featured serial port support and then support
+for FreeBSD kernel core dumps (vmcores).
+
+The LLDB client gained much improved support for connecting to the remote
+server over a serial port, and the LLDB server gained support for accepting
+communication over a serial port. This opened the possibility of using LLDB
+to debug embedded devices that use the RS232 interface. It can also aid
+debugging kernels on regular PCs as it does not rely on the network stack.
+
+Support for FreeBSD vmcores has also been added to LLDB. This makes it
+possible to inspect the crashed kernel state without having to resort to KGDB
+or manually convert the vmcore into the standard ELF format supported by LLDB.
+
+The introduced changes are expected to be shipped with LLDB 14.0.
+
+Sponsor: The FreeBSD Foundation
diff --git a/website/content/en/status/report-2021-10-2021-12/ls1027a.adoc b/website/content/en/status/report-2021-10-2021-12/ls1027a.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/ls1027a.adoc
@@ -0,0 +1,35 @@
+=== NXP LS1028A/1027A SoC support
+
+Contact: Kornel Dulęba <mindal@semihalf.com> +
+Contact: Artur Rojek <ar@semihalf.com> +
+Contact: Hubert Mazur <hum@semihalf.com> +
+Contact: Wojciech Macek <wma@semihalf.com>
+
+The Semihalf team has been working on adding the FreeBSD support for the link:https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/layerscape-processors/layerscape-1028a-applications-processor:LS1028A[NXP LS1028A] SoC, as well as its GPU-less variant (NXP LS1027A).
+
+NXP LS1028A/LS1027A SoC is a dual-core 64-bit ARMv8 Cortex-A72 application processor with high-speed peripherals such as 2 Time-Sensitive Networking-capable (TSN) Ethernet controllers, quad-port TSN-enabled switch, PCIE, SD/MMC, USB3.0 and others.
+
+The original support was extended in the following way:
+
+* ENETC Ethernet link:https://cgit.freebsd.org/src/log/sys/dev/enetc[driver]
+** Add support for PHY interrupts
+** Fix VID/mcast address hash calculation
+** Serialize MDIO transactions
+** Allow loading driver as a module
+* Improvements in the link:https://cgit.freebsd.org/src/log/sys/dev/sdhci/sdhci_fsl_fdt.c[FSL SDHCI driver]
+** Add support for HS200/HS400 modes
+** Add full support for software reset
+** Provide more accurate clk calculation
+** Implement pulse width detection errata
+** Fix vccq reconfiguration
+* FLEX SPI NOR controller link:https://cgit.freebsd.org/src/log/sys/dev/flash/flexspi/flex_spi.c[driver]
+* Additional features:
+** TMP461 thermal sensor link:https://cgit.freebsd.org/src/log/sys/dev/iicbus/tmp461.c[driver]
+** PCF85063 RTC driver link:https://cgit.freebsd.org/src/log/sys/dev/iicbus/rtc/pcf85063.c[driver]
+** TCA6408 I2C GPIO expander link:https://cgit.freebsd.org/src/log/sys/dev/iicbus/gpio/tca6408.c[driver]
+
+TODO:
+
+* Improve MMC HS200/HS400 support for other SoCs using the FSL SDHCI controller.
+
+Sponsor: Alstom Group
diff --git a/website/content/en/status/report-2021-10-2021-12/membarrier-rseq.adoc b/website/content/en/status/report-2021-10-2021-12/membarrier-rseq.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/membarrier-rseq.adoc
@@ -0,0 +1,103 @@
+=== sched_getcpu(2), membarrier(2), and rseq(2) syscalls
+
+Contact: Konstantin Belousov <kib@FreeBSD.org>
+
+Links: +
+link:https://kib.kiev.ua/kib/membarrier.pdf[Linux manpage for membarrier(2)] URL: link:https://kib.kiev.ua/kib/membarrier.pdf[https://kib.kiev.ua/kib/membarrier.pdf] +
+link:https://reviews.freebsd.org/D32360[membarrier(2) implementation] URL: link:https://reviews.freebsd.org/D32360[https://reviews.freebsd.org/D32360] +
+link:https://kib.kiev.ua/kib/rseq.pdf[Linux manpage for rseq(2)] URL: link:https://kib.kiev.ua/kib/rseq.pdf[https://kib.kiev.ua/kib/rseq.pdf] +
+link:https://reviews.freebsd.org/D32505[rseq(2) and userspace bindings implementation] URL: link:https://reviews.freebsd.org/D32505[https://reviews.freebsd.org/D32505]
+
+Linux provides a set of syscalls that allow to develop mostly
+syscall-less scalable algorithms in userspace. The mechanisms are
+based on optimistic execution using CPU-local data with the assumption that
+rare events like context switches or signal delivery do not occur
+for the given calculation, and if they do occur, rollback and restart
+is performed. This very high-level approach is used, as I understand,
+for implementation of tools like URCU, fast malloc allocators
+(tcmalloc) and other userspace infrastructure projects aimed at
+large partitioned machines.
+
+For instance, sched_getcpu(2) syscall returns the CPU id of the CPU
+where the current thread is currently executing. On amd64, if
+available, we use a RDTSCP or RDPID instruction to query the CPU id without
+changing CPU mode, otherwise this is a light-weight syscall. Of
+course, the answer provided is obsolete the moment it is created,
+even before it is returned to userspace. But it allows seeding values
+in some structures that are valid for a long time (at the
+CPU speed scale) and are automatically corrected on exceptional
+control flow events like context switches, and userspace can either detect
+and rollback or sync and rollback with the exceptions.
+
+There are two cornerstone syscalls that allow userspace to implement
+these efficient algorithms: membarrier(2) and rseq(2).
+
+Membarrier is a facility that helps implementing fast CPU ordering
+barriers, typically used for asymmetric/biased locking. In these lock
+implementation schemes, the owner of the object often assumes that there
+are contenders/parallel threads that need coordinating with. If some
+thread starts accessing the same resource, then it is its duty to
+ensure correctness. Examples of 'traps' that fast code path
+utilize are reads from a dedicated page that is unmapped by contenders,
+to switch the fast path to the slow one. Or we could send a signal to all
+threads that potentially have access to that object, to insert a
+barrier. Or we can use the membarrier(2) facility, which incurs
+significantly less overhead than signalling all threads.
+
+Membarrier(2) inserts a barrier, which is the typical underlying
+hardware operation to ensure ordering, into the specified set of CPUs,
+if these CPUs are executing the specified thread. If these CPUs are not executing
+the targeted threads, it is assumed that sequential consistency guarantees
+from the context switch are enough to fulfill the requirement of
+membarrier(2). Overall, the fast path can be implemented without slow
+instructions, and the slow path injects required fences into the fast path at
+the cost of IPI.
+
+The facility to detect exceptional conditions in the userspace thread
+execution was developed in Linux and called rseq(2). It is a feature
+often called Restartable Atomic Sequences, which explains the acronym.
+The ability to cheaply do that allows code longer than a single
+instruction to execute atomically, without the need to propose and
+implement unsafe operations like disabling preemption, which is not
+feasible for userspace. For instance, code might use CPU-local
+resources, which otherwise does not cope well with context switches.
+There cannot be an analog of critical_enter(9) in userspace. (A
+facility to cheaply block signal delivery exists in FreeBSD, see
+sigfastblock(2), but correctly using it is provably too hard to
+implement in general-purpose code, esp. because it requires
+version-dependent coordination with rtdl and libthr.)
+
+rseq(2) takes per-thread block of memory, where the thread writes the
+current CPU id (see sched_getcpu(2)) and specifies the block of
+critical code that must be unwound if an exceptional situation like a
+context switch occurred while the block was executing. The fast code
+path uses per-cpu data and typically does not need any corrections,
+but would a context switch occur, transfer of control to the abort
+handler informs userspace about the event. So instead of disabling
+context switches, code can cheaply check for one after the calculation
+and retry if needed.
+
+An interesting rseq(2) implementation detail is that it is
+impossible (and not needed) to access/update rseq structures from
+kernel during the actual context switch, because we cannot access
+userspace from under a spinlock. In other words,
+threads using rseq do not incur any performance cost from
+system-global context switches. Instead, if the process registered for
+rseq(2), on any return to user mode we check if any exceptional
+events happened while the thread was in the kernel (context switches may happen
+only while the thread is in kernel mode), and if a context switch indeed
+occured, we fire an ast to check whether the program counter is inside the
+critical section and jump to the abort handler if it is.
+
+The implementations of membarrier(2) and rseq(2) are clean-room: I used
+Linux manual pages as the reference and public discussions of the
+features for clarifying corner cases. On Linux/glibc, there was no
+stable glibc interface to the rseq facility. One proposed integration was
+committed then reverted from glibc. It might be prudent to wait
+some more for the rseq(2) interface to stabilize in glibc before providing
+it in our libc or to rely on tight integration between kernel
+and userspace in our base system, and use ABI tricks like symbol
+versioning to evolve the interface. There is no goal to be 100%
+compatible with Linux anyway.
+
+Sponsor: The FreeBSD Foundation
diff --git a/website/content/en/status/report-2021-10-2021-12/ocf-wg.adoc b/website/content/en/status/report-2021-10-2021-12/ocf-wg.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/ocf-wg.adoc
@@ -0,0 +1,20 @@
+=== Kernel Crypto changes to support WireGuard
+
+Contact: John Baldwin <jhb@FreeBSD.org>
+
+During the past few months, I merged several changes to the kernel to better
+support the WireGuard driver. These include extensions to the 'struct
+enc_xform' interface to better support AEAD ciphers, changes to 'struct
+enc_xform' to support multi-block operations for improved performance, and the
+addition of the XChaCha20-Poly1305 AEAD cipher suite to OCF. Additionally, the
+kernel now includes a new "direct" API for ChaCha20-Poly1305 operations on
+small, flat buffers. A change in review adds an API to support curve25519
+operations. With these changes, the WireGuard driver is mostly able to use
+crypto APIs from the kernel rather than its internal implementations.
+
+In parallel I have been updating the WireGuard driver to use the new
+APIs verifying interoperability with the existing driver. One of the
+next tasks is to refine these changes (along with some minor bug
+fixes) as candidates for upstreaming into the WireGuard driver.
+
+Sponsor: The FreeBSD Foundation
\ No newline at end of file
diff --git a/website/content/en/status/report-2021-10-2021-12/office.adoc b/website/content/en/status/report-2021-10-2021-12/office.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/office.adoc
@@ -0,0 +1,26 @@
+=== FreeBSD Office Team
+
+Links: +
+link:https://wiki.freebsd.org/Office[The FreeBSD Office project] URL: link:https://wiki.freebsd.org/Office[https://wiki.freebsd.org/Office]
+
+Contact: FreeBSD Office team ML <office@FreeBSD.org> +
+Contact: Dima Panov <fluffy@FreeBSD.org> +
+Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
+
+The FreeBSD Office team works on a number of office-related software suites and tools such as OpenOffice and LibreOffice.
+
+Work during this quarter was focused on providing the latest stable release of LibreOffice suite and companion apps to all FreeBSD users.
+
+Latest and quarterly ports branches got a new branch (7.2) of the LibreOffice suite and updated to the 7.2.4 release while new preleases
+such as 7.2.5.RC2 and 7.3.0.RC1 are cooking in the WIP stage area.
+
+Meanwhile, our link:https://github.org/freebsd/freebsd-ports-libreoffice[WIP repository] got back a working CI instance again, thanks to Li-Wen Hsu.
+
+Also we are still working on the link:https://github.com/fluffykhv/freebsd-ports-boost[Boost WIP repository] to bring the latest Boost library to the ports.
+
+We are looking for people to help with the open tasks:
+
+* The link:https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=open&email1=office%40FreeBSD.org&emailassigned_to1=1&emailcc1=1&emailreporter1=1&emailtype1=substring&query_format=advanced&list_id=374316[open bugs list] contains all filed issues which need some attention
+* Upstream local patches in ports
+
+Patches, comments and objections are always welcome in the mailing list and bugzilla.
diff --git a/website/content/en/status/report-2021-10-2021-12/openssh.adoc b/website/content/en/status/report-2021-10-2021-12/openssh.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/openssh.adoc
@@ -0,0 +1,25 @@
+=== Base System OpenSSH Update
+
+Links: +
+link:https://www.openssh.com/[OpenSSH] URL: link:https://www.openssh.com/[https://www.openssh.com/] +
+link:https://lists.freebsd.org/pipermail/freebsd-security/2021-September/010473.html[Announcement to freebsd-security@] URL: link:https://lists.freebsd.org/pipermail/freebsd-security/2021-September/010473.html[https://lists.freebsd.org/pipermail/freebsd-security/2021-September/010473.html]
+
+Contact: Ed Maste <emaste@freebsd.org>
+
+OpenSSH, a suite of remote login and file transfer tools, was updated from
+version 8.7p1 to 8.8p1 in the FreeBSD base system.
+
+*NOTE*:
+OpenSSH 8.8p1 disables the ssh-rsa signature scheme by default.
+For more information please see the
+link:https://lists.freebsd.org/pipermail/freebsd-security/2021-September/010473.html[Important
+note for future FreeBSD base system OpenSSH update] mailing list post.
+
+OpenSSH supports
+link:https://en.wikipedia.org/wiki/FIDO2_Project[FIDO]/link:https://en.wikipedia.org/wiki/Universal_2nd_Factor[U2F]
+devices, and support is now enabled in the base system.
+
+Next steps include integrating U2F key devd rules into the base system,
+and merging the updated OpenSSH and FIDO/U2F support to stable branches.
+
+Sponsor: The FreeBSD Foundation
diff --git a/website/content/en/status/report-2021-10-2021-12/portmgr.adoc b/website/content/en/status/report-2021-10-2021-12/portmgr.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/portmgr.adoc
@@ -0,0 +1,36 @@
+=== Ports Collection
+
+Links: +
+link:https://www.FreeBSD.org/ports/[About FreeBSD Ports] URL: link:https://www.FreeBSD.org/ports/[https://www.FreeBSD.org/ports/] +
+link:https://docs.freebsd.org/en/articles/contributing/#ports-contributing[Contributing to Ports] URL: link:https://docs.freebsd.org/en/articles/contributing/#ports-contributing[https://docs.freebsd.org/en/articles/contributing/#ports-contributing] +
+link:http://portsmon.freebsd.org/[FreeBSD Ports Monitoring] URL: link:http://portsmon.freebsd.org/[http://portsmon.freebsd.org/] +
+link:https://www.freebsd.org/portmgr/[Ports Management Team] URL: link:https://www.freebsd.org/portmgr/[https://www.freebsd.org/portmgr/] +
+link:http://ftp.freebsd.org/pub/FreeBSD/ports/ports/[Ports Tarball] URL: link:http://ftp.freebsd.org/pub/FreeBSD/ports/ports/[http://ftp.freebsd.org/pub/FreeBSD/ports/ports/]
+
+Contact: René Ladan <portmgr-secretary@FreeBSD.org> +
+Contact: FreeBSD Ports Management Team <portmgr@FreeBSD.org>
+
+The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters.
+Below is what happened in the last quarter.
+
+We currently have 46,700 ports in the Ports Collection according to FreshPorts.
+There are currently 2,666 open ports PRs of which 611 are unassigned.
+This quarter saw 9,535 commits from 166 committers on the main branch and 644 commits from 62 committers on the quarterly branch.
+Compared to last quarter, this means a slight drop in the number of commits although more committers were active, and a slight increase in the number of open PRs.
+
+During the last quarter, we welcomed Dries Michiels (driesm@) and said goodbye to kuriyama@ and fjoe@.
+There was also a change in portmgr: adamw@ stepped down after five years of service and tcberner@ is now a full member of portmgr@.
+
+Three new USES were introduced:
+
+* magick to handle dependencies on ImageMagick
+
+* nodejs to provide support for NodeJS (with a new default version NODEJS=lts)
+
+* trigger to handle pkg triggers using the TRIGGERS variable
+
+The default version of PGSQL switched to 13.
+Furthermore, INSTALLS_ICONS has been replaced by a trigger on gtk-update-icon-cache and the macro is no longer functional.
+
+As always, there were some updates to "big" packages: pkg was updated to 1.17.5, Chromium to 94.0.4606.81_3, and Firefox to 95.0.2_1,2.
+Ruby 3.1.0 and Python 3.11 are now available for use by users and other ports.
diff --git a/website/content/en/status/report-2021-10-2021-12/pot.adoc b/website/content/en/status/report-2021-10-2021-12/pot.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/pot.adoc
@@ -0,0 +1,28 @@
+=== Containers & FreeBSD: Pot, Potluck & Potman
+
+Links: +
+link:https://pot.pizzamig.dev[Pot on github] URL: link:https://github.com/pizzamig/pot[https://github.com/pizzamig/pot] +
+link:https://potluck.honeyguide.net/[Potluck Repository & Project] URL: link:https://potluck.honeyguide.net/[https://potluck.honeyguide.net/] +
+link:https://github.com/hny-gd/potluck[Potluck on github] URL: link:https://github.com/hny-gd/potluck[https://github.com/hny-gd/potluck] +
+link:https://github.com/grembo/potman[Potman on github] URL: link:https://github.com/grembo/potman[https://github.com/grembo/potman]
+
+Contact: Luca Pizzamiglio (Pot) <pizzamig@freebsd.org> +
+Contact: Stephan Lichtenauer (Potluck) <sl@honeyguide.eu> +
+Contact: Michael Gmelin (Potman) <grembo@FreeBSD.org>
+
+Pot is a jail management tool that link:https://www.freebsd.org/news/status/report-2020-01-2020-03/#pot-and-the-nomad-pot-driver[also supports orchestration through Nomad].
+
+In the last quarter, a new release link:https://github.com/pizzamig/pot/releases/tag/0.14.0[0.14.0] with a number of fixes and features like the new copy-in-flv command was made available.
+
+Potluck aims to be to FreeBSD and Pot what Dockerhub is to Linux and Docker: a repository of Pot flavours and complete container images for usage with Pot and in many cases Nomad.
+
+Here we again had a busy quarter. All images have been rebuilt for FreeBSD 12.3 and pot 0.13.0. +
+Also the images that can be used to build a virtual data center like link:https://potluck.honeyguide.net/blog/nomad-server/[Nomad], link:https://potluck.honeyguide.net/blog/consul/[Consul] and link:https://potluck.honeyguide.net/blog/vault/[Vault] have received a lot more tender love and care and are meanwhile in pre-production use on a cluster at a fintech. +
+Not all these changes have yet been committed to the github repository though, this is planned for the next quarter.
+Additionally, new images like link:https://github.com/hny-gd/potluck/tree/master/openldap[multi-master OpenLDAP] have been added, too.
+
+Potman aims to simplify building Pot images with Vagrant and VirtualBox based on the Potluck approach, e.g. as part of a DevOps workflow for software development including testing and publishing them to a repository.
+
+Here we have not yet made a lot of headway with our plan to utilise Potman in the Potluck library build process but this is still on our TODO-list, like improving the documentation for using the Virtual DC images from the Potluck library.
+
+As always, feedback and patches are welcome.
diff --git a/website/content/en/status/report-2021-10-2021-12/vdso.adoc b/website/content/en/status/report-2021-10-2021-12/vdso.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/vdso.adoc
@@ -0,0 +1,82 @@
+=== VDSO on amd64
+
+Contact: Konstantin Belousov <kib@FreeBSD.org>
+
+A VDSO, or Virtual Dynamic Shared Object, is a shared object (more
+commonly called dynamic library) that is inserted into the executed
+image by a joint effort of the kernel and the dynamic linker. It does
+not exists on disk as a standalone .so, and there are no instructions
+in the ELF format that cause the insertion. It is done by the system
+to implement some functionality for the C runtime implementation
+components.
+
+FreeBSD already has a lot of features typically done using VDSO (in
+Linux), but really not requiring that complication. The main reason
+why it is possible is the often mentioned co-evolution of the kernel
+and C runtime. We can naturally introduce features that require
+implementation both in kernel, and support in the userspace parts,
+since FreeBSD is developed as a whole. Surprisingly, it also allows
+the kernel and dynamic linker to know much less (and not enforce
+anything) about userspace consumers of interfaces.
+
+For instance, a syscall-less wall clock was implemented long ago, by
+the kernel providing a time hands blob in the shared page, and the C
+library knowing about its location and the supported algorithms.
+There is no need for a VDSO that interposes some libc symbols or
+provides services that are named by known symbols to userland.
+
+From all the years of experience with this pseudo-VDSO approach, the
+only feature that was impossible to implement without providing real
+VDSO support was the signal trampoline DWARF annotations, for the
+benefit of stack unwinders.
+
+When the kernel delivers signal to userland, it changes some key
+registers (like the instruction pointer, the stack pointer, and
+whatever else is needed by the architecture) and pushes the saved
+image of the whole usermode CPU state (context) onto the user stack.
+Then, control is passed to a small piece of code located in the shared
+page (signal trampoline), which calls the user handler function and on
+return from the handler issues a sigreturn(2) syscall to reload the
+old context.
+
+From this description, it is clear that the state of the machine
+during trampoline execution is quite different from the normal C
+calling frames. Unwinders that handle things like C++ exceptions,
+Rust panics, or other similar mechanisms in specific language
+runtimes, need to understand the specialness of the trampoline frame.
+The current approach is to hardcode the detection of the trampoline,
+e.g. by matching the instruction pointer against sysctl
+kern.proc.sigtramp.
+
+DWARF annotations are enough to provide the required information to
+unwinders to make the trampoline frame not special anymore, but the
+problem is that there is no way for unwinders to find the annotation
+without introducing even more specialness. Instead, we can insert a
+VDSO that only serves to appear in the enumeration of DSOs loaded into
+the process, with either dl_iterate_phdr(3) (in-process) or r_debug
+(remote), with PT_GNU_EH_FRAME header pointing to the root of DWARF
+info.
+
+This is exactly what the VDSO on FreeBSD does: it wraps signal
+trampoline bits and their DWARF annotation (.cfi) into a shared
+object, which is put into the shared page and linked by rtld(1) into
+the set of preloaded objects upon image activation.
+
+Efforts were made to strip as many unneeded structures and as much
+padding as possible from the VDSO image, because it consumes space in
+the shared page. It was pushed as far as the common denominator of
+lld and ld.bfd allowed, with several tricks done by linker scripts and
+some use of seemingly undocumented linker options.
+
+We need at least two VDSOs for amd64: a 64-bit one for native binaries
+and a 32-bit one for ia32 binaries. With the size of each VDSO around
+1.5KB, space becomes really tight in the shared page, which needs
+space for other stuff as well, like timehands or random generator
+seeds.
+
+Build scripts enforce that VDSOs do not grow larger than 2K; if they
+do, we need to extend shared page to become at least two shared pages.
+Scripts also enforce that VDSO are pure position-independent, not
+requiring relocations for either code or metadata (.cfi).
+
+Sponsor: The FreeBSD Foundation
diff --git a/website/content/en/status/report-2021-10-2021-12/www.adoc b/website/content/en/status/report-2021-10-2021-12/www.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/www.adoc
@@ -0,0 +1,25 @@
+=== FreeBSD Website Revamp - WebApps working group
+
+Contact: Sergio Carlavilla <carlavilla@FreeBSD.org>
+
+Working group in charge of creating the new FreeBSD Documentation Portal and redesigning the FreeBSD main website and its components.
+FreeBSD developers can follow and join the working group on the FreeBSD Slack channel #wg-www21.
+The work will be divided into four phases:
+
+. Redesign of the Documentation Portal
++
+Create a new design, responsive and with global search. (_Complete_)
++
+Activate an edit link in the Documentation (books/articles) pointing to GitHub and encouraging GitHub pull requests. (_Complete_)
+
+. Redesign of the Manual Pages on web
++
+Scripts to generate the HTML pages using mandoc. (_Work in progress_)
+
+. Redesign of the Ports page on web
++
+Ports scripts to create an applications portal. (_Work in progress_)
+
+. Redesign of the FreeBSD main website
++
+New design, responsive and dark theme. (_Not started_)
diff --git a/website/data/en/news/news.toml b/website/data/en/news/news.toml
--- a/website/data/en/news/news.toml
+++ b/website/data/en/news/news.toml
@@ -1,5 +1,10 @@
# Sort news by year, month and day
+[[news]]
+date= "2022-03-10"
+title = "October-December 2021 Status Report"
+description = "The <a href=\"https://www.freebsd.org/status/report-2021-10-2021-12/\">October to Decmeber 2021 Status Report</a> is now available with 19 entries."
+
[[news]]
date= "2022-02-09"
description = "New committer: <a href=\"mailto:asiciliano@FreeBSD.org\">Alfonso S. Siciliano</a> (src)"

File Metadata

Mime Type
text/plain
Expires
Fri, Dec 27, 2:12 AM (11 h, 25 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
15610145
Default Alt Text
D34521.diff (59 KB)

Event Timeline