diff --git a/website/content/en/status/report-2024-01-2024-03/cloud-init.adoc b/website/content/en/status/report-2024-01-2024-03/cloud-init.adoc index 3a49bb4bff..1410966cf0 100644 --- a/website/content/en/status/report-2024-01-2024-03/cloud-init.adoc +++ b/website/content/en/status/report-2024-01-2024-03/cloud-init.adoc @@ -1,34 +1,34 @@ === FreeBSD as a Tier 1 cloud-init Platform Links: + link:https://cloud-init.io/[cloud-init Website] URL: link:https://cloud-init.io/[] + link:https://cloudinit.readthedocs.io/en/latest/[cloud-init Documentation] URL: link:https://cloudinit.readthedocs.io/en/latest/[] + Contact: Mina Galić cloud-init is the standard way of provisioning servers in the cloud. Over the past year and a half, thanks to this FreeBSD support has steadily improved. This year, together with cloud-init developers and the FreeBSD Foundation, we decided to explicitly focus on making improvements in FreeBSD itself, that will aid the cloud-init team to test future changes to FreeBSD code-paths themselves. To achieve this goal, I need to make FreeBSD run in LXD (and Incus), under the control of ``lxd-agent`` (or ``incus-agent``). Here are some improvements from the recent weeks: - I have written a small link:https://codeberg.org/meena/test-cloud-init[testing-framework] (in sh, and I'm slowly porting it to OpenTofu/Terraform), which installs the latest version of package:net/cloud-init-devel[] or package:net/cloud-init[] and runs a couple of standard cloud-init tests. - To do this, I have created a link:https://pkg.igalic.co/[dedicated public repository] which contains the latest versions of package:net/cloud-init-devel[] and package:net/cloud-init[] for FreeBSD 13 and 14 on amd64 and aarch64. - I have link:https://codeberg.org/meena/vsock-tests[ported Linux's vsock testing framework to FreeBSD] - I created a driver skeleton for a link:https://codeberg.org/meena/freebsd-src/src/branch/vsock/sys/dev/virtio/socket[VirtIO Socket driver], based on the HyperV Socket driver. - In doing so, I made numerous link:https://reviews.freebsd.org/D44517[improvements to HyperV sockets], some of which are accepted, others still need more work. - I have tested and released the latest 24.1 series cloud-init, where the cloud-init team and I have finally fixed some longstanding bugs, such as link:https://github.com/canonical/cloud-init/pull/4820[moving ``/run/cloud-init``] to [.filename]#/var/run/cloud-init# on BSD, as well as fixing the link:https://github.com/canonical/cloud-init/pull/5061[``homedir`` argument] to ``user_groups`` to actually do something. - This release also sees numerous fixes to the OpenBSD code-paths from the community and not just me. - I have also started an official port for OpenBSD, but link:https://marc.info/?l=openbsd-ports&m=170508174230708&w=2[that work has stalled]. The work to come, in broad strokes: - Finish the FreeBSD VirtIO Socket driver. - Fix Go's runtime to support VirtIO on FreeBSD. - Port lxd-agent's dependencies to FreeBSD. - Port lxd-agent to FreeBSD. -That work will be interspersed with more improvments to cloud-init on BSDs, and more tests on different cloud providers. +That work will be interspersed with more improvements to cloud-init on BSDs, and more tests on different cloud providers. Sponsor: The FreeBSD Foundation diff --git a/website/content/en/status/report-2024-01-2024-03/gcc.adoc b/website/content/en/status/report-2024-01-2024-03/gcc.adoc index 9fdecb0f40..1f39cb172e 100644 --- a/website/content/en/status/report-2024-01-2024-03/gcc.adoc +++ b/website/content/en/status/report-2024-01-2024-03/gcc.adoc @@ -1,25 +1,25 @@ === GCC on FreeBSD Links: + link:https://gcc.gnu.org/[GCC Project] URL: link:https://gcc.gnu.org/[] + link:https://gcc.gnu.org/gcc-10/[GCC 10 release series] URL: link:https://gcc.gnu.org/gcc-10/[] + link:https://gcc.gnu.org/gcc-11/[GCC 11 release series] URL: link:https://gcc.gnu.org/gcc-11/[] + link:https://gcc.gnu.org/gcc-12/[GCC 12 release series] URL: link:https://gcc.gnu.org/gcc-12/[] + link:https://gcc.gnu.org/gcc-13/[GCC 13 release series] URL: link:https://gcc.gnu.org/gcc-13/[] Contact: Lorenzo Salvadore link:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273397[Updating GCC default version to 13] is finally finished. Thanks to mailto:antoine@FreeBSD.org[Antoine Brodin] who ran the exp-runs and to all other developers and ports maintainers involved. As promised in the preceding report, the next goal is to reduce the number of open bugs for GCC ports. Some work on existing bugs has already started. In particular, package:lang/gcc14-devel[] has long stayed out of date due to some issues with building the port without any BOOTSTRAP option. Thanks to the help of other developers and contributors (a special thank to Mark Millard), I noticed that according to the official documentation link:https://gcc.gnu.org/install/prerequisites.html[building GCC without bootstrap requires a working GCC binary] and thus I switched package:lang/gcc14-devel[] to require that a BOOTSTRAP option is set. -However it has later been stated that bootstraping GCC using clang and libc++ is link:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632[officially supported]. +However it has later been stated that bootstrapping GCC using clang and libc++ is link:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632[officially supported]. But it has also been stated that this is not a high priority. At the moment package:lang/gcc14-devel[] is the only GCC port requiring a BOOTSTRAP option to be set. The plan is to have all GCC ports for versions greater or equal than 14 (i.e. future GCC ports) to require such an option: even if building without bootstrap is more or less officially supported, being low priority for upstream it increases the burden of maintaining GCC ports for low results. In case lower versions start to have issues building without bootstrap, I am going to require bootstrap for those as well. diff --git a/website/content/en/status/report-2024-01-2024-03/ten64-whle-honeycomb.adoc b/website/content/en/status/report-2024-01-2024-03/ten64-whle-honeycomb.adoc index 368e9a851b..2cd21e9767 100644 --- a/website/content/en/status/report-2024-01-2024-03/ten64-whle-honeycomb.adoc +++ b/website/content/en/status/report-2024-01-2024-03/ten64-whle-honeycomb.adoc @@ -1,37 +1,37 @@ === Ten64, WHLE-LS1, and HoneyComb Links: + link:https://wiki.freebsd.org/BjoernZeeb/[My wiki page with links to some status] URL: link:https://wiki.freebsd.org/BjoernZeeb/[] + Contact: Bjoern A. Zeeb Solid-Run's HoneyComb, Traverse Technologies's Ten64 and some versions of Conclusive Engineering's WHLE-LS1 all are NXP based platforms with the Data Path Acceleration Architecture Gen2 (DPAA2). Work has happened to support or improve support for peripherals on these boards. For DPAA2 I have local changes which will need review (or further discussion): * Cleanup of memac (MDIO) code reducing bus attachment (ACPI and FDT specific) code into more common code. * Cleanup of MC bus attachment code (again ACPI, FDT). * For reasons of mii_fdt.c support on some PHYs on FDT-based platforms restructure MAC/MII code and mostly migrate it out of the network interface (NI). * Improve Dmitry Salychev's (dsl) initial SFF/SFP code, prototyping a bus similar to MII for SFP with the hope that with more work it can grow into a larger, general FreeBSD framework and hooked it up to DPMAC. * With this, minimal support (still fairly hacked up) for "managed" SFP+ mode (using the Ten64 terminology) is usable on FDT-based systems using DAC and fiber cables. * Add more sysctl statistics to DPMAC and NI. -In short, I mostly cleaned up some of the mess I contributed to during the initial bringup. +In short, I mostly cleaned up some of the mess I contributed to during the initial bring-up. For the LS1088a based WHLE-LS1 systems changes include: * device-tree file updates. * Added support for the PCA9546 I2C Switch (committed). * Added basic support for the PCAL6524 24-bit Fm+ I2C-bus/SMBus I/O expander. * Added basic support for the PCA9633 4-bit Fm+ I2C-bus LED driver to drive the status LEDs. * Added support to program the man:rgephy[4] LEDs (which needs to be validated). * Started testing the eMMC with MMCCAM and GENERIC but had trouble (needs further investigation, seemed fine from firmware for updates). * Tested one of three PCIe slots and USB fine. For the Ten64: * Most of the basic lifting happened a while ago and it has generally been usable. * Detecting the VSC8514 PHY as such went in end of last year. * Used as the default platform to test the DPAA2 changes and SFP/SFP+ code. In addition Pierre-Luc Drouin has overhauled the Vybrid I2C support now attaching and working on both FDT- and ACPI-based systems (committed). Sponsor: Traverse Technologies (Ten64 hardware a while ago, support) diff --git a/website/content/en/status/report-2024-01-2024-03/wireless.adoc b/website/content/en/status/report-2024-01-2024-03/wireless.adoc index 9fc1ec6102..0f77129009 100644 --- a/website/content/en/status/report-2024-01-2024-03/wireless.adoc +++ b/website/content/en/status/report-2024-01-2024-03/wireless.adoc @@ -1,21 +1,21 @@ === iwlwifi(4) and wireless for 13.3-RELEASE Links: + link:https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=0[Categorised Wireless Problem Reports] URL: link:https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=0[] Contact: Bjoern A. Zeeb + Contact: The FreeBSD wireless mailing list -In the first weeks of 2024 focus was on stability for 13.3-RELEASE to finally make man:iwlwifi[4] useable. +In the first weeks of 2024 focus was on stability for 13.3-RELEASE to finally make man:iwlwifi[4] usable. The upcoming 14.1-RELEASE will benefit from this work too. The response has since generally been positive and man:iwlwifi[4] supporting chipsets up to BE200 seems mostly stable, yet still slow. A lot of testing was provided by the FreeBSD Foundation and by many users. Massive thanks to everyone who tested, reported back, updated PRs and helped other users. I have also slowly started to "categorise" more (old) wireless problem reports and will try to continue with some spring cleaning throughout the year. If you have questions or feedback please use the link:freebsd-wireless mailing list[https://lists.freebsd.org/subscription/freebsd-wireless]. That way everyone will see, be able to join in, and the answers will be publicly archived. Sponsor: minipci.biz (BE200 hardware)