As of r354833 the FreeBSD base system now includes flua: (F)reeBSD Lua.
In this post, I kind of describe the design goals of flua and use of this new tool in the base system.
First: What is it?
Flua is the lua scripting language for use in the FreeBSD base system. It is based on the canonical Lua 5.3.
This implementation is shared with FreeBSD's bootloaders and used by default in FreeBSD 12.0 and later (perhaps a topic for another day) for driving the menu system and other small enhancements to the early boot process, so this version is notably devoid of floating point support as this is not supported in the loader environment.
Flua also includes some partially-implemented subset of modules that are generally available in ports. The set of modules included in flua and the extent to which they're actually implemented is completely subject to change based on the needs of the base system. More on this later.
What can it be used for?
We only advocate use of flua for base system components. No warranty or guarantee is provided for flua; it may change at any time. Requests for additions to flua may be considered depending on the use-case, but ultimately the implementation will reflect the needs of the base system and any reasonable uses by downstream projects.
What is it currently used for?
Currently, flua is only used to generate various syscall-related files via the top-level sysent target. This use replaced a shell script that featured a mix of POSIX shell, sed, and awk to do the same task.
Proposals for things that can be written or rewritten in flua are welcome for discussion. ldconfig is one tool that's been proposed for rewriting in flua, with the goal of being usable by other lua scripts. pkg in particular could use this, as it recently started gaining support for sandboxed lua scripts. ldconfig is somewhat commonly executed in post-install scripts.
Modules
Currently, the following modules are partially implemented in flua:
- lposix
- lfs
All modules written for flua will be built-in C modules that should be compatible with a module of the same name available from ports in the parts that are actually implemented.
The general idea and goal is that we don't necessarily need all of the features of, say, lposix, but we should always be able to point to ports and indicate a set of ports you can install to completely replace flua without losing any functionality of the scripts that target flua. In this way, flua doesn't provide any unique functionality that cannot be obtained from ports; it merely provides a means to use this functionality in base system components.
Flua Style
Lua in the base system actually does have a style guide: style.lua(9)
One may also reference various examples throughout the tree:
- ^/stand/lua/*.lua
- ^/sys/tools/makesyscalls.lua
Flua style is fairly fluid and still being somewhat explored.