So far, my focus has been towards the kernel side of the audio stack, with D43545 being probably the most requested and notable patch. I am also working on scrapping the rather outdated "snd_clone" audio device cloning framework of sound(4) , and replacing it with DEVFS_CDEVPRIV(9) ( D44411 ).
The FreeBSD audio stack is one of those fields that does not attract the same attention and development as others do, since it has been left largely unmaintained, and, although high in quality, there is still room for improvement — from lack of audio development frameworks, to missing userland utilities and kernel driver-related bugs. This project is meant to touch on all those areas, and as such, is more of a general improvement project, than an implementation of a specific feature.
Feedback is obviously very welcome — on the existing content as well as any additional content we should be looking into!
once this lands, we can move to a more widespread update to the overall content
we also have a review ( D43940 ) up for an initial step to improving the bhyve man page
If you want to know more about our work, come join us at one of Michael Dexter’s weekly bhyve production users calls or reach me by email .
An initial release is already in ports as sysutils/vmstated and updates are pending commit; however, the newest version can be found on GitHub. We are considering expanding the work; we would also like to invite anyone interested to join us in this work! Patches, suggestions, feedback, etc. are all very much welcome!
vmstated is configured via a UCL configuration file (similar to jails.conf) and — in combination with a man:bhyve_config|5] configuration file — already provides highest flexibility in configuring virtual machines. vmstatedctl provides a jail-like command set to start, stop, and retrieve status information about guests. State transitions can easily be hooked via shell scripts and allow running additional commands for network or storage set up and tear down when relevant state changes occur.
Started as an experiment to better understand the problem space of process supervision and virtual machine state handling, vmstated is constructed of a daemon and vmstatedctl management utility. It is built with base-only tooling and libraries and leverages FreeBSD specific constructs like kqueue to minimize its resource impact.
Technically, this means working out existing gaps around process supervision and virtual machine state management. First steps were taken by experimenting with existing frameworks (i.e. s6rc work by Jan Bramkamp) and eventually — through discussions in the weekly bhyve production user’s calls (organized by Michael Dexter) — this led to a proof-of-concept implementation of "vmstated".
While other desirable features were identified as well, i.e. TPM software emulation and snapshot/restore/host-migration, the conceptual tooling question won over those due to the lower degree of complexity and its clarity on goal and the path on how to take steps towards it.
Last year, Greg Wallace at the FreeBSD Foundation founded the Enterprise Working Group with the specific goal of addressing pain points of Enterprise users of FreeBSD. One of the work groups that emerged clustered around bhyve and jails management tooling. After collecting a set of desired features and functionality, one overarching key point for bhyve emerged: the desire to have configuration concepts and tooling for bhyve like the ones available for jails.
We plan to continue discussing our results during Michael Dexter’s weekly bhyve production users call - come join us if you are interested. We also hope to be able to present the results at EuroBSDCon in Q3.
We are also pitting results for different CPU manufacturers against each other and contrasting guest vs host performance to better understand the performance impact of virtualization.
Participants of the weekly bhyve production users calls recently discussed bhyve’s I/O performance. Various ways of measuring and comparing were brought up, however it was quickly clear that there is currently no formal analysis and report on this. So, we started this effort in the hopes of better understanding the various impacts of configuration options for a guest on its I/O performance. We created a set of shell scripts that harness a FreeBSD guest for running benchmarks/fio I/O performance measurements under various configurations. This allows us to compare multiple criteria like bandwidth, latency, IOPS, and more.
Graphical Installer for FreeBSD
Contact: Pierre Pronchery <pierre@freebsdfoundation.org>
The first hurdle to overcome when testing a new Operating System is to get it installed. What is more, the first impression new users gather from an Operating System is its installation process. The state of the art for Operating System installers nowadays definitely involves a graphical process. This is the case for mainstream systems but also for other UNIX systems comparable to FreeBSD: RedHat Enterprise Linux, Ubuntu, Debian GNU/Linux, or even Devuan GNU+Linux Regardless of the technical level of the actual user, this is how the platform will be compared in the public eye.
In practice, FreeBSD has already been derived as a desktop-oriented Operating System by different projects. Of these, I only found GhostBSD as a maintained project offering a graphical procedure to install the system. The objective here was to consider a procedure that FreeBSD could adopt as part of its base system, in order to ship a graphical installer much like the current installer. However, GhostBSD’s installer relies on a Gtk+ interface driven with Python, implying a hefty footprint on the installation media when adopting FreeBSD’s usual image generation procedure. It would also imply importing and maintaining new projects into the ports tree.
Instead, with knowledge of the current bsdinstall(8) and bsdconfig(8) utilities, I envisioned a BSD-licensed replacement for Xdialog(1). Just like when invoking bsdconfig with the -X switch for graphical mode, it could be dropped in instead of bsddialog(1) and allow graphical installation - while sharing the infrastructure of the current installer. To avoid confusion with the current implementation of Xdialog from the x11/xdialog port, I have named its replacement gbsddialog(1). It also has to be said that Xdialog is quite obsolete (latest release in 2006) and this shows visually too.
After creating a Proof-of-Concept prototype past the 14.0 release, I was provided with a 2-months window by the FreeBSD Foundation, in order to complete a working implementation. Thanks to a few shortcuts, I was glad to present the outcome of this effort during the WIP session of AsiaBSDCon 2024, including a working graphical installer.
Most of the necessary patches are already available for review in FreeBSD’s Phabricator:
I have tried to keep these patches in growing order of friction expected before integration.
The most important objective of this project was to improve bsdinstall, regardless of the success of this integration. From the items above, it should be noted that D44279, D44280, D44670 are expecting to improve the general look & feel of the installer, even while in text mode. Similarly, D44671 and D44672 improve the overall versatility of the installer when scripted or customized. D44673 and D44674 bring it on par with bsdconfig -X, even allowing the graphical installation of jails.
Some parts are still missing, or made use of shortcuts still unsuitable for integration:
The "fetchmissingdists" target was avoided by shipping every component on the installation media;
The "checksum" and "extract" targets had to be re-implemented with simpler code, degrading the user experience also with the regular installer;
Creation of the installation media generates an additional, heavy image (almost 8 GB), and is suspected to be hindered by a bug in makefs(8).
The corresponding code can be found in my GitHub fork in the khorben/bsdinstall-graphical4 branch. As can be guessed from the branch name, depending on the complexity of rebasing operations, combined with the (hopefully) progressive integration of the changes proposed, new branches may be added to keep track of the progress. (In fact a khorben/bsdinstall-graphical5 branch already exists.)
Still, a lot needs to be done for the installer to reach a new level of maturity overall. While working on this project, I have received general complaints on the installer, and calls for a complete rewrite. It is true that the current code base suffers from a number of issues and limitations. The lack of a graphical installer is one of many symptoms, which range from the lack of recovery from errors, of navigability to previous steps, of a general vision of the installation progress, or of a network-based installer. In the meantime, this is the installer we have and are familiar with, and I think it can still be saved and improved.