diff --git a/website/content/en/status/report-2022-10-2022-12/cloud-init.adoc b/website/content/en/status/report-2022-10-2022-12/cloud-init.adoc index 371e0c8959..ead9082e65 100644 --- a/website/content/en/status/report-2022-10-2022-12/cloud-init.adoc +++ b/website/content/en/status/report-2022-10-2022-12/cloud-init.adoc @@ -1,23 +1,23 @@ === FreeBSD as a Tier 1 cloud-init Platform Links: + link:https://cloud-init.io/[cloud-init Website] URL: link:https://cloud-init.io/[https://cloud-init.io/] + link:https://cloudinit.readthedocs.io/en/latest/[cloud-init Documentation] URL: link:https://cloudinit.readthedocs.io/en/latest/[https://cloudinit.readthedocs.io/en/latest/] + -link:https://github.com/canonical/cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst[cloud-init ongoing refactorization] URL: link:https://github.com/canonical/cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst[https://github.com/canonical/cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst] +link:https://github.com/canonical/cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst[cloud-init ongoing refactorization] URL: link:https://github.com/canonical/cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst[https://github.com/canonical/cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst] Contact: Mina Galić cloud-init is the standard way of provisioning servers in the cloud. Unfortunately, cloud-init support for operating systems other than Linux is rather poor, and the lack of cloud-init support on FreeBSD is a hindrance to cloud providers who want to offer FreeBSD as a Tier 1 platform. To remedy the situation, this project aims to bring FreeBSD cloud-init support on par with Linux support. The broader plan is to lift support across all BSDs. The first milestone has been delivered. Along with many bug fixes, we now have link:https://github.com/canonical/cloud-init/pull/1779[merged] an man:ifconfig[8] parser, which allows us to retrieve all the information of all network devices, similarly to how on Linux this is done by parsing the contents of `/sys/class/net//`. In the coming weeks, this project will align itself with the Azure developers to do some crucial refactoring. This will move our new parser further into cloud-init's main execution paths. People interested in helping with the project can help with testing new features and fixes through package:net/cloud-init-devel[], which will be updated whenever we make significant commits. Further, people with access to, and experience with, OpenBSD and NetBSD are also highly welcome to help. Sponsor: The FreeBSD Foundation diff --git a/website/content/en/status/report-2022-10-2022-12/gcc.adoc b/website/content/en/status/report-2022-10-2022-12/gcc.adoc index 67dacde9e7..47ed95c948 100644 --- a/website/content/en/status/report-2022-10-2022-12/gcc.adoc +++ b/website/content/en/status/report-2022-10-2022-12/gcc.adoc @@ -1,50 +1,50 @@ === GCC on FreeBSD Links: + link:https://gcc.gnu.org[GCC Project] URL: link:https://gcc.gnu.org[https://gcc.gnu.org] + link:https://gcc.gnu.org/gcc-11/[GCC 11 release series] URL: link:https://gcc.gnu.org/gcc-11/[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/[https://gcc.gnu.org/gcc-12/] Contact: Lorenzo Salvadore + ==== Update GCC default version to 12 - + Thank you very much to antoine@ for running the necessary exp-runs and to all the contributors, maintainers and committers involved in the process. As was noted last quarter, for every major version of GCC, FreeBSD usually awaits the release of the second minor version to update GCC default version. However next time I would like to attempt to update the default version as soon as the first minor version of GCC 13 is out. The rationale for awaiting the second minor release was to wait for other operating systems (in particular Linux distributions) to find, report, and fix bugs, so that FreeBSD could focus mainly on FreeBSD-specific cases. But this also meant that upstream software developers only heard from FreeBSD rarely, and mostly when it concerned FreeBSD only, thus our operating system risks being considered minor and unimportant for them. My hope is that software authors can value supporting FreeBSD more as the number of its contributions to other projects also increases. Of course I understand that this will imply more work for all ports maintainers and I will do my best to help them as much as I can. link:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265948[https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=2659548] ==== Resolution of a conflict preventing the installation of multiple GCC versions simultaneously - + Now, lang/gcc11 and lang/gcc12 can be installed at the same time. This was particularly important for the update of the GCC default version, since a few ports have been kept to compile with GCC 11 for now. Note however that at the moment only one -devel GCC port at the time can be installed on your system. This is because I have patched the standard ports only: for the -devel port I expect upstream to fix the issue soon, by using a link:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491[patch submitted by a FreeBSD user] or link:https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606450.html[my own patch], or using some other solution. link:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257060[https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257060] ==== D language D is now enabled in lang/gcc11 and lang/gcc11-devel, thanks to diizzy. I plan to include D support for higher versions of GCC too, but this cannot be done as easily as for GCC 11 due to bootstrapping issues: starting from GCC 12, the D compiler GDC needs a working GDC to be built. link:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266825[https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266825] ==== Crashes with -fsanitize=address Software compiled with GCC using the `-fsanitize=address` switch has been reported to crash. I have fixed the issue for lang/gcc11, lang/gcc11-devel, lang/gcc12, and lang/gcc12-devel. I am still working on lang/gcc13-devel. Use of the address sanitizer requires ASLR to be disabled. As GCC gets the code that I am modifying from LLVM, and LLVM is also included in the FreeBSD src repository with some patches that improve ASLR detection and automatically re-run programs with ASLR disabled when necessary, I am also merging those patches. link:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267751[https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267751] diff --git a/website/content/en/status/report-2022-10-2022-12/status.adoc b/website/content/en/status/report-2022-10-2022-12/status.adoc index 67d3311890..dcc1682c0a 100644 --- a/website/content/en/status/report-2022-10-2022-12/status.adoc +++ b/website/content/en/status/report-2022-10-2022-12/status.adoc @@ -1,61 +1,61 @@ === Status reports: New workflow Links: + link:https://www.freebsd.org/status/[FreeBSD status reports] URL: link:https://www.freebsd.org/status/[https://www.freebsd.org/status/] + link:https://github.com/freebsd/freebsd-quarterly[Status reports GitHub repository] URL: link:https://github.com/freebsd/freebsd-quarterly[https://github.com/freebsd/freebsd-quarterly] Contact: ==== Goals of the new workflow This quarter the status team has been discussing with doceng@ some improvements to its workflow. In particular, the team is attempting to merge its GitHub repository into the FreeBSD doc/ repository. Here are the reasons for such a change: * having two independent repositories requires spending some time to make sure that both are in sync, which is being done manually. See for example commits such as link:https://github.com/freebsd/freebsd-quarterly/commit/4b8255e604dd0513e841aa8f3dce7741e78b999c[https://github.com/freebsd/freebsd-quarterly/commit/4b8255e604dd0513e841aa8f3dce7741e78b999c], which are not immediately clear in their commit messages about what is being done unless more time is invested to copy commit messages properly; -* the FreeSD doc/ repository is self-hosted, while the status repository is hosted on GitHub. +* the FreeBSD doc/ repository is self-hosted, while the status repository is hosted on GitHub. Since the contents of the self-hosted repository are mirrored, nothing is being lost in visibility with the repository merging. Some inconsistencies about the name of the team have also been found: the team has been referred to as "quarterly", "quarterly status team", "status", "status team", "monthly" etc. So this issue is also being addressed. Please note that we are still working on these changes and that they might not be completed within the next quarter. The status team will take care to keep all information about report submissions up to date so that you always know how to submit your reports. ==== Team naming Since "quarterly" might refer to quarterly reports but also to quarterly branches, using "quarterly" only could cause some confusion in some contexts. "quarterly-status" is likely a bad idea as well, as the frequency of reports publication might need to change in the future. Thus just "status" has been chosen: this is correct as quarterly status reports contain information about the status of the development of FreeBSD, it is frequency-agnostic and consistent with link:https://www.freebsd.org/status/[its FreeBSD website section]. The following link:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267813[email addresses have been created]: * the main contact address for the status team is now . Mails sent to `quarterly@FreeBSD.org` will still reach the team, but you are encouraged to use the new address; * the email address for the status report submissions is now . Mails sent to `quarterly-submissions@FreeBSD.org` will still reach the team, but you are encouraged to use the new address; * the `quarterly-calls` mailing list has been renamed to link:https://lists.freebsd.org/subscription/freebsd-status-calls[status-calls]. If you were already subscribed to `quarterly-calls`, you do not need to resubscribe. ==== Report submission Three different ways to submit reports will be provided: * submitting a review on Phabricator. A new link:https://reviews.freebsd.org/project/profile/88/[Phabricator group] called "status" link:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267812[has been created]. If you would like to give a hand to the team by reviewing reports we suggest you add yourself to the group 'watchers'; * submitting a pull request at link:https://github.com/freebsd/freebsd-doc/pulls[https://github.com/freebsd/freebsd-doc/pulls]; * sending an email to `status-submissions@FreeBSD.org`. Reviewing processes will proceed as they usually do on each of these channels. ==== Other changes * The repository merging will require reworking some of the existing tools to better integrate with the existent structure of the FreeBSD doc/ repository. * The link:https://github.com/freebsd/freebsd-quarterly[status reports GitHub repository] will be archived once the new workflow implementation is completed. diff --git a/website/content/en/status/report-2022-10-2022-12/xen.adoc b/website/content/en/status/report-2022-10-2022-12/xen.adoc index 879c6af0fb..3070e9b08c 100644 --- a/website/content/en/status/report-2022-10-2022-12/xen.adoc +++ b/website/content/en/status/report-2022-10-2022-12/xen.adoc @@ -1,36 +1,36 @@ === FreeBSD/ARM64 on Xen Links: + link:https://www.xenproject.org/[Xen Project] URL: link:https://www.xenproject.org/[https://www.xenproject.org/] + link:https://wiki.freebsd.org/Xen[FreeBSD wiki page on Xen] URL: link:https://wiki.freebsd.org/Xen[https://wiki.freebsd.org/Xen] Contact: Elliott Mitchell Xen is an open source hypervisor. Xen is one of the earliest hypervisors and has support for many OSes. Since FreeBSD 8.0, GENERIC FreeBSD/x86 has been able to run on Xen. Near the time FreeBSD was ported to run on Xen, work was started on running Xen on ARM. For a number of years Linux has run fine on Xen/ARM, but FreeBSD hasn't been available. Having FreeBSD/ARM64 on Xen means any system capable of having Xen can also have FreeBSD in operation. Of note, the Raspberry PI 4B has hardware (GICv3) which Xen works with. If you're okay with Linux handling the hardware, you can use all the hardware of a Raspberry PI 4B. In 2014 a proof of concept of running FreeBSD/ARM64 on Xen was done by Julien Grall, but this was never polished for release. During the past 2 years I've been working towards having this in FreeBSD's tree, so released versions of FreeBSD/ARM64 would run on Xen. At this point all changes which need to be shared with the x86 Xen source code have been reviewed (not all reviews are on Phabricator). This now awaits testing by Roger Pau Monné before being committed to FreeBSD's tree. I now urgently need someone with a high level of familiarity with the interrupt subsystem of FreeBSD on ARM64 to review (and commit) the ARM-specific portions. My builds are functional far more often than they fail, and most failures are temporary problems in FreeBSD's tree. -Some significant issues will need to be addressed regarding FreeBSD's interrupt subsytem. +Some significant issues will need to be addressed regarding FreeBSD's interrupt subsystem. There is substantial hope of having FreeBSD/ARM64 available for "DomU" (unprivileged) operation for FreeBSD 14.0. There is potential for FreeBSD/ARM and FreeBSD/RISC-V to run on Xen in short order. No plans currently exist for having FreeBSD/ARM64 operating as the controlling VM (someone could try to sponsor this). ==== Thanks Thanks to Julien Grall for the Proof of Concept. + Thanks to Roger Pau Monné for reviewing changes involving x86. + Thanks to Mitchell Horne for helping with various FreeBSD/ARM64 issues and addressing a key problem with FreeBSD/ARM64.