This is another post in the series “A Personal Multi Installer in Lua”.

• 3) FreeBSD “Multi” Installer at BSDCan 2026. <- This post
• 2) Proof of Concept for a “Multi” Installer.
• 1) Motivations and Ideas for a “Multi” Installer.

The previous blog post described the proof-of-concept implementations of the installer subsystems and introduced the first mockups (graphical interfaces without any underlying logic) for the installation steps. That version was presented at EuroBSDCon 2025 in Zagreb.

Current Status

The project has evolved significantly. Compared to the version shown in Zagreb, I have completely refactored and rewritten several core parts of the installer, including:

• The configuration file.
• The communication file (used to exchange data between Step 1 and Step 2).
• The installer subsystems (internationalization, multi-mode support, and others).
• The Step 1 and Step 2 managers.
• The component framework, where the installation screens are now managed and invoked by the Step 1 Manager.
• Many installation screens/steps.

The installer was presented at BSDCan 2026 in Ottawa, Canada. The presentation slides are available here: https://docs.google.com/presentation/d/1QBWZyg2fdSmfs7xdZ1Jxg6-5I1iawoGweXVVk7tVlHk/edit?usp=sharing

The presentation provides an overview of the project’s current status. The installation via TUI frontend is now almost complete.

The final slides also outline:

• The implementation roadmap.
• Work in progress (WIP).
• Planned TODO features.

As always, feedback, suggestions, and new ideas are very welcome.

A system call is the mechanism through which user-space software requests services from the kernel. In the FreeBSD operating system, more than 400 system calls are available, forming the core interface between applications and the kernel.

These system calls are defined in the syscalls.master file, which serves as the authoritative source. This file is processed by the System call creation library to automatically generate several key components, including init_sysent.c, syscall.h, and others that implement and expose the system call interface.

At the time of writing, the system call table for FreeBSD 16-CURRENT includes 603 entries: 15 unimplemented, 53 marked as nosys or lkmnosys, 48 for compatibility, and 75 considered old or obsolete. The entry point of a system call usually follows the sys_{name} naming convention, with the exceptions of syscall and __syscall, which are described below.

This table is partly auto-generated by scanning init_sysent.c and then completed manually. It’s mainly intended for my own study of the FreeBSD kernel, so it shouldn’t be considered an authoritative source.

Table

syscall and __syscall

syscall and __syscall do not have dedicated sys_syscall() or sys___syscall() entry points. Instead, the architecture-dependent implementation handles SYS_syscall and SYS___syscall. It uses kern/subr_syscall.c and the function syscallenter() is responsible for dispatching the handler for the indirect system call.

sigreturn

The entry point is sys_sigreturn but its implementation is machine-dependent.

Extra links

• Source Code: /src/sys/.
• Developers’ Handbook: A.3. System Calls.
• Wiki Page: Adding Syscalls.

nsysctl project is a utility for FreeBSD built on top of the sysctl system call. It allows users to query and modify kernel parameters at runtime. The release 2.2 is out!

The previous version (1.2.1) was released almost two and a half years ago. It just worked, so no changes or improvements were necessary. Recently, WebSysctl was launched, it uses the XML data generated by nsysctl to populate its database. With new users adopting nsysctl, several feature requests were submitted, and they have been implemented in this new release

NEWS

This release includes support for options that were added to the sysctl(8) utility over the past couple of years.

CHANGELOG:

2025-6-28 Version 2.2

    * improve: updated and refined nsysctl.8 manual page
    * change: -G no longer prints redundant flags RW, CAPRW, RDTUN, RWTUN
    * rename: -V (print parameters without values with -a) to -u, because below
    * add: new -V to print objects with the VNET flag; sysctl(8) compatibility
    * rename: -l (print label) to -L, because below
    * add: new -l to print value size; sysctl(8) compatibility
    * add: new -J to print objects with the PRISON flag; sysctl(8) compatibility
    * delete: -m (now -S) and -y (now -O) from the manual; obsolete since 2.0
    * add: -j <jailname> to attach to a jail

DOCS

Both the manual and the tutorial have been updated to reflect the latest changes.

% nsysctl 
usage: nsysctl [--libxo options [-r tagroot]] [-DdeFGgHIiJLnOpqTtVvWz]
               [-N | -hl [b|o|x]] [-B bufsize] [-f filename] [-j jailname]
               [-s sep] name[=value[,value]] ...
       nsysctl [--libxo options [-r tagroot]] [-DdeFGgHIJkLnOpqSTtVvWz]
               [-N | -hlu [b|o|x]] [-B bufsize] [-f filename] [-j jailname]
               [-s sep] -a

INSTALLATION

To install the port sysutils/nsysctl:

# cd /usr/ports/sysutils/nsysctl/ && make install clean

To add the package:

# pkg install nsysctl

To build from sources:

# pkg install libsysctlmibinfo2
% git clone https://gitlab.com/alfix/nsysctl.git
% cd nsysctl
% make
% ./nsysctl

SysctlTUI is a text-based utility that allows users to view and modify the FreeBSD kernel state at runtime via a text user interface built on top of sysctl(3).

This is the manual:

SYSCTLTUI(8)            FreeBSD System Manager's Manual           SYSCTLTUI(8)

NAME
     sysctltui - TUI utility to get or set system state

SYNOPSIS
     sysctltui [-h | -v]
     sysctltui [-d | -V] [-f] [-e label] [-l label] [-i indent] [-s label]

DESCRIPTION
     The sysctltui utility provides a text user interface (TUI) for retrieving
     and modifying system state at runtime.  System parameters are exposed as
     objects of a "Management Information Base" (MIB).  sysctltui sysctltui
     allows users to navigate the MIB, display the properties of a parameter,
     and retrieve or modify its value.

     sysctltui requires the sysctlinfo(4) interface.  To load the required
     kernel module at boot time, place the following line in loader.conf(5):

           sysctlinfo_load="YES"

     The following options are available:

     -d      Show parameter descriptions in the main window.

     -e label
             Set label as prefix for nodes with expandable subtree, default
             "+".

     -f      Display full parameter names in the main window.  The full name
             of the parameter currently in focus within the main window is no
             longer shown at the bottom of the screen.

     -h      Print a help message and exit.

     -i indent
             Set indent as the visual depth of subtrees.

     -l label
             Set label as prefix for leaf nodes, default no string.

     -s label
             Set label as prefix for nodes with expanded subtrees, default
             "-".

     -V      Display parameter values in the main window

     -v      Print version and quit.

EXIT STATUS
     The sysctltui utility exits 0 on success, and >0 if an error occurs.

COMPATIBILITY
     Layout similar to sysctl(8) and nsysctl(8):
           % [n]sysctl -a           % sysctltui -fV -i 0
           % [n]sysctl -an          % sysctltui -f -i 0
           % [n]sysctl -ad          % sysctltui -fd -i 0

SEE ALSO
     sysctlview(1), sysctl(3), sysctlmibinfo2(3), sysctlinfo(4), nsysctl(8),
     sysctl(8)

AUTHORS
     sysctltui was written by Alfonso Sabato Siciliano
     <asiciliano@FreeBSD.org>.

FreeBSD 15.0-CURRENT             June 8, 2025             FreeBSD 15.0-CURRENT

The sysctl() system call can get or set the state of the system, the FreeBSD kernel exposes the parameters for sysctl() as objects of a Management information Base (MIB).

sysctltui is a Text User Interface sysctl MIB explorer. It allow to view a parameter’s properties and get or set its value. The first version 0.0.1 is out.

Getting Started

# pkg install sysctlmibinfo2 bsddialog
% git clone https://gitlab.com/alfix/sysctltui.git
% cd sysctltui
% make
% ./sysctltui

The utility provides three windows: a main one with the tree, one to view information about the parameter, and one to set a new value.

Main Window:

Parameter Properties:

Set Value:

Usage

% ./sysctltui -h
usage: sysctltui [-h|v]
       sysctltui [-d|V] [-f] [-e <label>] [-l <label>] [-i <indent>] [-s <label>]

 -d		Show parameter descriptions in the main window.
 -e <label>	Set prefix for nodes with expandable subtree.
 -f		Display full parameter names in the main window.
 -h		Show this help message and exit.
 -i <indent>	Set the visual depth of subtrees.
 -l <label>	Set prefix for leaf nodes.
 -s <label>	Set prefix for nodes with expanded subtrees.
 -V		Display parameter values in the main window.
 -v		Show version and exit.

Tip, layout similar to sysctl or sysutils/nsysctl:

sysctltui is still in its early stages; it is currently at version 0.0.1. It provides some functionality similar to nsysctl and sysctlview, but many features still need to be implemented.

TODO list:

• Add: [View] menu: Rebuild Tree, Expande Tree, Collapse Tree, Show desc, Show Value, Clear screen.
• Add: kelvin format.
• Add: Opaque(s).
• Improve: sort children.
• Add: /etc/sysctl.conf and /boot/loader.conf.

Suggestions, feedback, and new ideas are welcome.

The FreeBSD Operating System provides the sysctl system call and utility to get and set system state at runtime. The kernel exposes available parameters for sysctl as objects in a Management Information Base (MIB).

Today, FreeBSD includes thousands of sysctl parameters. Moreover, parameters can be added or removed dynamically. Each computer probably builds a different MIB. To help navigate this, the kernel provides additional features for exploring the MIB and retrieving extra information about each object (such as name, description, format, and so on).

WebSysctl aims to collect all possible sysctl parameters along with their properties.

The MIB is represented as a table, list. and a tree.

Additionally, WebSysctl provides a page for each parameter, available both in dot notation (for example, kern.ostype) and in path notation (for example, kern/ostype).

Currently WebSysctl is available at http://websysctl.alfonsosiciliano.net/. It will probably move to alfonsosiciliano.dev in the future. (I already own the domain but I am waiting to obtain an SSL certificate. I will post updates on this blog.)

Please note: I am not a web/frontend/backend/full-stack developer, nor a database expert. WebSysctl is my first web project, and it can certainly be improved.

This is another post in the series: “A Personal Multi Installer in Lua”.

• 2) Proof of Concept for a “Multi” Installer <- this post
• 1) Motivations and Ideas for a “Multi” Installer

This post describes the current Work in Progress with screenshots and previews. Please refer to the previous post for more background information.

The idea is that a client creates an installation file, and a server performs the installation. A proof of feasibility is available:

• installer.lua reads the configuration file and builds the start menu.
• installer.lua calls client.lua.
• client.lua uses the configuration file and the selected frontend (currently TUI and CLI) to create the installation file.
• installer.lua calls server.lua
• server.lua reads the installation file and actually performs the installation on the machine.

The installer is independent of any graphical interface. Both the client and the server use a generic “Frontend” object, and they are unaware of its specific implementation. The installer can also run without a user interface:

• The client can create the installation file by reading the default values from the configuration file or through auto installation.
• The server can execute the installation commands without a user interface.

That is a non-interactive installation. The installer provides several options for interactive, semi-interactive, and non-interactive installations, which will be described later in this post.

The installation file acts as the communication file between the client and server. Additionally, it offers two useful features:

1. It can be reused.
2. It can function as a standalone installer.

More details will follow.

The installer skeleton is complete and serves as a proof of concept. It meets most of the requirements and features outlined in the first post: multi-language, multi-frontend, multi-way, and multi-interactivity.

Configuration File

The installer starts by reading the configuration file, which allows you to fully customize the installer settings. It also includes options from bsdinstall. Here is a snippet:

------------------------------------------------------------
--- Starting configuration, you can set up the installer ---

-- Clone bsdinstall OSNAME
Config.OSNAME = "FreeBSD"

-- Clone bsdinstall EFI_LABEL_NAME
Config.EFI_LABEL_NAME = "FreeBSD"

-- Logging and debug
Config.LOGGING_FILE = "/tmp/install.log"
Config.LOGGING_LEVEL = 3

-- Start menu beep: at start up and after restart (accessibility)
-- Config.BEEP = true

-- Client creates Config.INSTALLATION from this configuration file and the
-- user interface. The server reads it to perform the installation on the
-- machine.
-- If Config.CLIENT=false this should be an existing file for the server.
Config.INSTALLATION = "/tmp/installation.lua"

-- Enable client. If disabled the installer will run only the server, so be sure
-- Config.INSTALLATION already exists.
Config.CLIENT = true

-- Enable server
Config.SERVER = true

-- Directory to store "etc" files during server installation,
-- clone bsdinstall BSDINSTALL_TMPETC
Config.TMP_ETC = "/tmp"

.....

--------------------------------------------------------------------------------
-- Screens to show to the user. It is possible to set default values ​​for some
-- screens. If the screen is disabled but the default value is set, it will be
-- written in the INSTALLATION file.

-- Start Menu
Config.SCREEN_STARTMENU = true

-- Hostname
Config.SCREEN_HOSTNAME = true
Config.SCREEN_HOSTNAME_VALUE = HOSTNAME

.....

Then, the installer builds the Start Menu. Three beeps sound to inform blind and low-vision users that they can start the installation (more on this later).

Expert Menu

The Expert Menu (Start Menu > Advanced --->) offers various features. For example”

“File Installation” allows you to select an installation file. The file can be manually created, generated from a previous installation, or generated from the configuration file. If the file exists, the installer skips the client step and directly starts the server. Of course the client can be disabled via the configuration file, to run a semi- or non-interactive installation by reading an installation file.

“Logging” lets you choose a debugging/logging level.

Just a log snippet:

====================================================
= Starting Installer Sat Mar 15 14:17:49 2025
====================================================
DEBUG: Loaded configuration file: "config.lua"
DEBUG: load "./i18n.lua"
DEBUG: load "./configure.lua"
DEBUG: load "./startmenu.lua"
DEBUG: load "./client/client.lua"
DEBUG: load "./userinterface/frontend.lua"
DEBUG: load "./client/hostname.lua"
DEBUG: load "./server.lua"
DEBUG: load "./userinterface/cli.lua"
DEBUG: call ./userinterface/frontend.lua:16 new()
	(arg) self = object table: 0xad707088880
	(arg) o = nil
DEBUG: load "./userinterface/gui.lua"
DEBUG: load "./userinterface/tui.lua"
DEBUG: call ./userinterface/frontend.lua:16 new()
	(arg) self = object table: 0xad707088880
	(arg) o = {
		__tostring = "TUI",
	}
DEBUG: load "./userinterface/web.lua"
DEBUG: call ./configure.lua:17 newInstallationTable()
DEBUG: call ./userinterface/tui.lua:146 new()
	(arg) self = object Frontend
DEBUG: call ./startmenu.lua:171 run()

.....

====================================================
= Start Client
====================================================
DEBUG: call ./client/client.lua:49 loop()
	(arg) ui = {
		__tostring = "TUI",
		new = function,
		menu = function,
		radiolist = function,
		inputString = function,
		hostname = function,
		highContrast = function,
		message = function,
		question = function,
	}
.....

====================================================
= Start Server
====================================================

...

Reading Installation file "installation.lua"
DEBUG: load "installation.lua"
Read Installation file "installation.lua"
DEBUG: call ./server.lua:8 shell()
	(arg) cmd = "BSDINSTALL_TMPETC=/tmp HOSTNAME=laptop.bsd
		./bsdinstall/hostname"
----- Command ----
BSDINSTALL_TMPETC=/tmp HOSTNAME=laptop.bsd ./bsdinstall/hostname
	1>/tmp/lua_u0OmXk 2>/tmp/lua_QeM98G
rv: 0
out: err: 
-----------------

.....

---------------- Dialog -------------------------
bsddialog --backtitle 'Installing FreeBSD 15.0-CURRENT'
--title ' Complete ' --no-label 'Shell'
--ok-label 'Reboot' --extra-button --extra-label 'Shutdown'
--yesno 'Installation Complete. Thank you to use FreeBSD!'
0 0  2>/tmp/lua_VZ6R
Button: Shutdown (dialog rv:3)
stderr: 
------------------------------------------------
====================================================
= End Installer Sat Mar 15 14:18:19 2025
====================================================

Main Menu

Returning to the Start Menu.

You can switch to “Dark Theme” for improved visibility.

The installer supports multiple frontends and can seamlessly switch to CLI mode using a simple key combination (“S + Enter”) to ensure screen reader compatibility. Special thanks to the FreeBSD Foundation for making this possible. It’s important to note that this is currently just a draft and will be improved further.

The i18n (internationalization) module is implemented, allowing language selection through the “Language” option.

If a translation is unavailable, the default English text is used. To note “Beep” “Disabled”.

Client Loop

The client provides its features in a loop, so it is easy to implement:

• Multi-way installation
• Navigation buttons

After selecting “Install”, choose between Auto, Simple, or Expert installation modes.

Each screen includes navigation buttons: [Prev], [Restart], and [Next].

After selecting [Restart], you can choose between Soft, Hard, or Reboot.

New guideline: each screen has to provide an help (F1 key).

Server

The server prompts for confirmation before reading the configuration file and proceeding with the OS installation.

If an error occurs, it displays the failed command along with the return value, stdout, and stderr.

In verbose mode, the executed command is also displayed; please see Expert Menu above.

Multi interactive

The configuration file offers extensive flexibility to customize user interactivity levels: interactive, semi-interactive, and non-interactive.

The setup is the combination of Start Menu (Enable/Disabled) + Client UI (Enabled/Disabled (also for each screen)) + Client (Enabled/Disabled) + Server UI and Verbose (Enabled/Disabled).

Fully Interactive (user driven) Installation example:

• Start Menu enabled + client enabled + client UI enabled + server UI and Verbose enabled

Fully Non-Interactive (no user interaction) Installation examples:

• Client UI disabled (client generates the installation file from default values or auto mode) + server UI and Verbose disabled
• Alternatively, if the installation file already exists: the client disabled, the installer directly passes the installation file to the server with UI and Verbose disabled.

Standalone Installer

The installation file is both a client/server communication file and a standalone installer. Here is a snippet:

--- Installation file created on Sat Mar 15 00:25:54 2025 ---
	
-- Uncomment the following line to use this file like a standalone installer.
-- Example, run: '# lua /root/installation.lua'.
-- local standaloneInstaller = true

local installation = {
	version = "15.0-CURRENT",
	[1] = {
		label = "hostname",
		command = "BSDINSTALL_TMPETC=/tmp HOSTNAME=fbsd.mtc ./bsdinstall/hostname"
		}, -- End hostname
	[2] = {
		label = "date",
		command = {
.....

} -- End Installation

local function install()
	for _, step in ipairs(installation) do
		if type(step.command) == "table" then
			for _, c in ipairs(step.command) do
				os.execute(c)
			end
		else
			os.execute(step.command)
		end
	end
end

if standaloneInstaller then install() end
.....

To use the file as a standalone installer, uncomment the line:

-- Uncomment the following line to use this file like a standalone installer.
-- Example, run: '# lua /root/installation.lua'.
local standaloneInstaller = true

And execute:

# lua /root/installation.lua

WIP and Future

Currently finishing reading Programming in Lua, 4th Edition.

Integrating bsdinstall components and adding progress bars to the server:

Currently, server.lua simply loads the installation file and executes its commands, adding only logging and a user interface. In pseudocode:

--Server.lua

installation = load("installation file")

for step in (installation)
	execute(step.command)
	log(step.namen step.command)
	UI.window(step.name, step.comman)
end

I am considering merging server.lua with the installation file so it becames a simple sequence of commands.

The server uses a lightweight version of the bsdinstall components, without a user interface and logging. For example, the hostname script becomes:

# Default file to store hostname entry in
: ${HOSTNAMEFILE:=$BSDINSTALL_TMPETC/rc.conf.hostname}

# Store the user's choice
echo hostname=\"$HOSTNAME\" > $HOSTNAMEFILE
retval=$?

# Activate entry if configured
if [ "$BSDINSTALL_CONFIGCURRENT" ]; then
	hostname -s $HOSTNAME
	retval=$?
fi

exit $retval

I am also considering rewriting the shell components in Lua.

Adding a final step to install a desktop environment, ports, and packages for accessibility. For example:

I am considering to integrate this project to provide the web frontend.

Finally, I am working on improvements and extensions for the partitioner. Several feature requests exist, primarily on Bugzilla.

This post is a list of “I would like this feature installing the operating system”. Motivations and implementation plan.

I spent my “Open Source 2022” working around bsdinstall, the FreeBSD OS installer. Weekly I replaced the Text User Interface (TUI) frontend dialog/libdialog with bsddialog/libbsddialog in a component (an utility in C or a shell script) and I tested the installer/ISO generated the previous week. The challenges were: the partitioner, the mixedgauges, and implementing the features for bsdconfig, anyway the task was really interesting. During the weeks I wrote notes with new ideas and features to improve bsdinstall. Unfortunately I had a sudden medical problem in autumn 2022. I could not sit in front of the computer for many months. Obviously I had no time to implement my ideas. Baptiste finished the replacement.

I started working again in mid-2023. My open source effort was to improve the accessibility for vision impairment users. bsdinstall uses a TUI frontend, TUI is a well-known accessibility problem, screen readers (both speech synthesizer and Braille display) cannot “read” TUI. So the installer is not acessible for blind users. The best solution is a new Command Line Interface (CLI) frontend, fortunately it will be sponsored by the FreeBSD Foundation for the Vision Accessibility project. This will be a proof of concept and research project, so far only a Google’s paper addresses the topic of accessible CLI. However adding a new frontend to bsdinstall is not trivial, the task requires heavy changes. Actually I do not know if I can add a new frontend totally different from dialog.

Spring 2024, I started thinking about a redesign for the installer. Of course I can add also many other features a in a new project, most require a re-design/rewrite of the current installer. The new project could be available like a port and a script to generete an ISO so anyone can download and adapt the installer to their needs. Furthermore, I have received some requests, for example several people would like something in Lua. July 2024, I wrote an email to hackers mailing list to collect extra tips and ideas, other suggestions were received during EuroBSDCon. I hoped to finish by 6/8 months, but a medical issue (related to the previous one) blocked me, end-2024. However, this time the therapy worked, and after 2 years the doctors gave good news.

2025, maybe it’s time to start. Some project choices, ideas and requirements:

Guidelines:

• Simple, modularized and extendable.
• Compatible with bsdinstall.
• Backend (Server side) and frontend (Client side).
• “Multi-”: multi-language, multi-frontend, multi-mode, multi-interactivity

Requirements and features

• Of course Open Source under a BSD-Like license.

• An option to select bsdinstall or this installer at start-up.

• Logging and debug features similar to bsdinstall with extensions.

• Improvements and extensions for the partitioner. Several feature requests exist, mainly on bugzilla.

• A configuration file with variables, hooks, comments and examples.

  • Provide bsdinstall variables and configuration files. Ideally these features will be placed in the “centralized” configuration file above.

• Multi installation process:

  • Interactive. The server waits for the user input from the frontend, then it performs the “command”.
  • Noninteractive. No user actions. Server reads previously written files: by hands, by a previous installation, by a fake installation.

• Server side written in Lua, modularized in scripts. Independent of any frontend. Probably using bsdinstall components (their logic without UI), of course adding extra features.

• Frontend responsible only for User Interface.

• Backend <-> Frontend communication via text files. To evaluate also a Lua layer, etc.

• Multi-language: English, French, Spanish, and so on.

• Multi-mode installation: [Automatic], [Simple], and [Expert].

• Multi-frontend. Implementation priority:

  • Text User Interface. Similar to bsdinstall with new features.
  • File. Settings are read from text file(s).
  • Command Line Interface. Suitable for a screen reader for vision impairments users.
  • Graphical User Interface.
  • WEB. TBD, I am not a web-expert. A proof of concept is available.

• A menu to select: frontend and other options, at start-up. A possible example:

The Command Line frontend could be similar to portoptscli, an utility to set up port options suitable for screen readers. Demo (turn on audio):

• Frontends have to be totally separated from the backend, eventually to be easily added/deleted/changed/improved in the future. This is the learned lesson by adding bsddialog to bsdinstall.

• New UI/UX features (something is related to the server side):

  • Navigation. New buttons: [Restart], [Prev], and [Next] for each screen.
  • Dialogs for help, at start-up and during installation (F1 or [Help] button).
  • High Contrast theme for color blind and low vision users.
  • Final step to install ports and packages for accessibility.
  • Final step to install a desktop environment. Some possible examples:

Other Requests

Groups and laptop/desktop users are collecting feature requests. They make sense and should be implemented. Suggestions and new ideas are welcome, feel free to contact me.

Current Status, Plan, Timing.

Now: studying Lua, reading “Programming in Lua, 4th Edition”.

Implementation Plan: Implement bsdconfig logging and debug features in a Lua lib. Write a Lua chunk to call a bsdinstall component. Define a “communication” file for backend <-> frontend. Delete TUI from the bsdinstall component and start to write a frontend. At this point it should be easy to add: the other bsdinstall components, the “Requirements and features”, and requests from desktop users. This project is supposed to be tedious but simple. The challenge is the partitioner, but I have already rewritten its frontend in the past.

Timing: I hope to finish by September at least 3 frontends. I’ll try posting updates.

MixerTUI is an audio mixer with a terminal user interface (TUI) for the FreeBSD sound system. It allow to switch easily between laptop and HDMI, headphones and speakers, and so on. Features include: show the current driver configuration, select an audio device to get information, change the volume, or make the device the default. The version 1.5 is out!

To install the port audio/mixertui:

# cd /usr/ports/audio/mixertui/ && make install clean

To add the package:

# pkg install mixertui

To build from sources:

Step 1. Install deps

# pkg install bsddialog libsysctlmibinfo2

Step 2. Download, build, and run

% git clone https://gitlab.com/alfix/mixertui.git
% cd mixertui
% make
% ./mixertui

Version 1.5 Changes and Improvements

1) Pop-ups are implemented using libbsddialog, for example the screenshot shows a bsddialog menu. Curiosity, the first version of bsddialog was just a copy of the mixertui pop-ups to implement dialogs, now mixertui uses libbsddialog to show pop-ups.

2) Improvements for the menu to select the device/pcm. The item with the default pcm (sysctl hw.snd.default_unit) has the “(Default)” prefix; pcm4 in the screenshot. Opening the menu the selected item is the current pcm; pcm2 in the screenshot.

3) Fix fault with terminals without colors. Example

% env TERM=vt220 mixertui

4) Few internal refactoring. Probably this is the last C/ncurses version, (see Future subsection below).

Future

MixerTUI started out as a personal project (…game :D). I spent 30 minutes to set up my microphone to record my BSDCan presentation during the first lockdown. I set audio quickly via alsamixer in the past. Now my main laptop runs FreeBSD, so I wrote mixertui to avoid to waste time setting up a microphone, headphones, accessibility, and so on.

The first version was just 1000 lines of code; mainly ncurses stuff because the sound system interface is actually easy: just some ioctl and sysctl. However several users started to use it. I received a lot of tips, feedback, merge request, iussues, email, and so on.

The utility grew messy to implement the user requests. Mainly I spent time to use libncurses, because it does not provides widgets (buttons, title, bars, …), it is just a “render” library. I would have preferred to spend time implementing new audio features instead of “drawing” a bar. ncurses is not suitable. I am considering other TUI libraries to rewrite MixerTUI in the next version 2.0. Under the radar: brick/haskell, tui-rs/rust, FTXUI/C++.

Conclusion, this is just a TUI improvements version. I’ ll rewrite mixertui. TODO, Ideas and new audio features in the future: mouse, virtual_oss, devd, sound(4) improvements, accessibility, and so on.

The FreeBSD 3q2023 status report is online!

My contribution is PortOptsCLI (Port Options CLI), a new utility to select the port options using a Command Line Interface. It is suitable for a speech synthesizer (currently tested with the speech synthesizer of accessibility/orca), so it is accessible to users with vision impairment.

To know more:

• Port(7) manual.
• Ports handbook.
• PortOptsCLI - Ports Collection Accessibility.
• Project repository https://gitlab.com/alfix/portoptscli.
• Manual PortOptsCLI(1).

The FreeBSD Operating System provides the Ports Collection to give users and administrators a simple way to install applications.

It is possible to configure a port before the building and installation. The configuration consists of a set of lists: checklists to enable or disable an option, radiolist to select at the most one option. Some list is mandatory, at least one option has to be active.

ports-mgmt/dialog4ports and ports-mgmt/portconfig allow to set up a port via an interactive Text User Interface. They are implicitly used by “make config”, example editors/vim port:

# cd /usr/ports/editors/vim
# make config

The black and white theme can provide high-contrast accessibility for users with low vision, for portconfig >= 0.6:

# env NO_COLOR="YES" make config

Older versions:

# env PORTCONFIG_THEME="blackwhite" make config

PortOptsCLI

Unfortunately screen readers perform terrible with TUI; it is a well-known accessibility problem. FreeBSD provides tens of thousands of ports; port configuration is a key feature, unfortunately it is inaccessible to users with vision impairment.

PortOptsCLI (Port Options CLI) is an utility for setting the port options via a Command Line Interface. Properly PortOptsCLI provides commands to navigate lists (checklists and/or radiolists) and set up their items interactively also suitable for a speech synthesizer. Currently it is tested with the speech synthesizer of orca https://wiki.gnome.org/Projects/Orca, FreeBSD provides a port and a package https://www.freshports.org/accessibility/orca/.

Preview https://twitter.com/alfsiciliano/status/1694858990440648711, video description and transcription are available in the Demo section later.

Getting Started

To install the port:

# cd /usr/ports/ports-mgmt/portoptscli/ && make install clean

or to install the package:

# pkg install portoptscli

After the installation, add to /etc/make.conf:

#DIALOG4PORTS?= ${LOCALBASE}/bin/dialog4ports
DIALOG4PORTS=${LOCALBASE}/bin/portoptscli

Now ‘make config’ uses portoptscli automatically. To start to set up a port are sufficient few commands:
h: specific port help if exist.
n: next element (header, list, option, end line).
p: previous element.
r: reprint current element.
space: enable or disable a checklist item, select a radiolist item.
a: abandon without saving.
q: save and quit.
All features are linked in the Documentation section later.

Demo

PortOptsCLI disables ECHO and ENTER. However this demo surrounds runtime commands and comments by square brackets in a new line for ease of understanding. To note some speech synthesizer can read the typed keys depending on the current setting.

# cd /usr/ports/editors/neovim
[ENTER]
# make config
[ENTER, start implicitly portoptscli]
Configuration for neovim-0.9.1 port, 1 list total 2 options.
[v]
Verbose mode on.
n: next, p: previous, r: reprint, space: select or unselect.
[n]
List 1. Generic options. Checklist with 2 options.
[n]
1 NLS: Native Language Support. Enabled.
[n]
2 PYNVIM: Enable support for plugins written in python. Disabled.
[SPACE]
option PYNVIM enabled.
[n]
End configuration. q: save and quit, a: abandon without saving, t: go to top.
[q]
Save and quit.
#

Another demo without commands and comments:

# cd /usr/ports/editors/vim
# make config
Configuration for vim-9.0.1671 port, 3 lists total 12 options.
Verbose mode on.
n: next, p: previous, r: reprint, space: select or unselect.
List 1. Generic options. Checklist with 3 options.
1 MAKE_JOBS: Enable parallel build. Disabled.
2 NLS: Native Language Support. Enabled.
3 XTERM_SAVE: Restore xterm screen after exit. Disabled.
option XTERM_SAVE enabled.
List 2. Optional language bindings. Checklist with 6 options.
1 LUA: Lua scripting language support. Disabled.
2 PERL: Perl scripting language support. Disabled.
3 PYTHON: Python bindings or support. Enabled.
4 RUBY: Ruby bindings or support. Disabled.
5 SCHEME: MzScheme (Racket) bindings. Disabled.
6 TCL: Tcl scripting language support. Disabled.
List 3. CTAGS. RadioList with 3 options, mandatory list select at least one option.
1 CTAGS_BASE: Use system ctags. Selected.
2 CTAGS_EXUBERANT: Use exctags instead of ctags.
3 CTAGS_UNIVERSAL: Use uctags instead of ctags.
option CTAGS_UNIVERSAL selected previous CTAGS_BASE unselected.
End configuration. q: save and quit, a: abandon without saving, t: go to top.
Save and quit.
#

Documentation

• Manual : $ man 1 portoptscli, online.
• README https://gitlab.com/alfix/portoptscli/-/raw/main/README.txt.

Tips

Verbose mode can be set by the PORTOPTSCLI_VERBOSE=“YES” environment variable.

The c key prints the short commands list described in the Getting Started:

# make config
Configuration for neovim-0.9.1 port, 1 list total 2 options.
[c]
Short commands list.
h: specific port help if exist.
i: port and lists info.
n: next element.
p: previouse element.
r: reprint element.
space: select or unselect an option.
a: abandon without saving.
q: save and quit.
[a]

===> Options unchanged
#

Some port has a specific help file, if it exists PortOptsCLI informs at startup/top, h key to print it:

# cd /usr/ports/devel/pcre/
# make config
Configuration for pcre-8.45_3 port, 2 lists total 6 options.
The port has a help file, h: to print.
[h]
Help file /usr/ports/devel/pcre/pkg-help.
Using the heap rather than the stack for recursion (i.e., turning the
STACK_RECURSION knob off) is slower but less prone to segfaults from
stack exhaustion when matching certain patterns.
End help file.
[a]

===> Options unchanged

Suggestions, bug report, new ideas

• My contacts for private discussions.
• FreeBSD Accessibility mailing list to share and to track discussions in a public place.

Extras

FreeBSD also allows you to configure a port using environment variables or configuration files, both ways are described in the port(7) manual.

Resources and links for further information:

• Ports intro, online.
• Manual: $ man 7 ports, online.
• /usr/ports/README, online.
• FreeBSD Handbook “4.5. Using the Ports Collection”, online.

Important: This post is now obsolete. Please refer to the FreeBSD 16 System Calls Table for the latest information.

A system call is the “tool” used by a software in the userspace to request a “service” to the kernel. The FreeBSD Operating System provides over 400 system calls. They are defined in syscalls.master, this file is processed by makesyscalls.lua to create: init_sysent.c, syscall.h, and so on.

The system calls list has 588 entries (15: unimplemented, 53: nosys/lkmnosys, 46: compat and 72: old/obsolete) for 15-CURRENT at the time of writing. The entry point of a system call is sys_{name}, except syscall and __syscall described below.

This table is partially auto-generated by scanning init_sysent.c and manually filled, indeed its purpose is just a personal study of the FreeBSD kernel.