However, it was conceived for extensibility and flexibility in general, in the spirit of [6]. It has been used also for scripting CPU frequency scaling, debugging, application sandboxing among others [7,8].
Potentially, yes. However, I didn't try it. You could even disable GC completely. Lunatik provides some facilities that could be useful in this scenario as well, such as RCU tables and shared objects. For instance, you could pre-allocate the entire memory to be used by your Lua states and treat them as volatile. In this case, you could persist state on the shared objects stored and synchronized through a RCU table. Of course, you could implement your own GC or tune the existent GC modes as well.
I'm currently working on updating XDPLua for using kfuncs on top of the newest version of Lunatik.. I've a PoC already and should create a PR in a few weeks.
Saying lua is bad is another way of saying "I don't understand lua." It could be better in many ways (especially syntactically), but it has no serious competition in the embeddable scripting language category.
> Kernel code is normally prohibited from using floating-point (FP) registers or instructions, including the C float and double data types. This rule reduces system call overhead, because the kernel does not need to save and restore the userspace floating-point register state.
> However, occasionally drivers or library functions may need to include FP code. This is supported by isolating the functions containing FP code to a separate translation unit (a separate source file), and saving/restoring the FP register state around calls to those functions. This creates “critical sections” of floating-point usage.
With this, we can proceed - easily! - to attain something I have long wanted: to replace all Linux userspace with Lua-only tooling. Yes, Lua all the things in userspace.
I know, "why would I do that?", well, because there is a thing I've wanted for 40 years of computing, and that is a very, very powerful computer that only requires me to use one (oh, okay, two or three..) languages.
I grew up in computers that booted directly to a single language (BASIC), and would let you do everything you need in that and only that. Imagine replacing all userspace tooling with a lua implementation. Yes, insane! But imagine the development flow once you get some good stuff ported/ffi'ed! Having the kernel interfaces available now, is just .. candy.
I would love to have this for a Linux distro, even experimental, even just as a toy, to boot directly into a LOAD81[1] interface that has a whole lotta new Lunatik in it .. I could imagine pushing LOAD81 very hard into a new OS paradigm with this. Wow!
One of the main inspirations for Lunatik is the MS Singularity OS [1], which gets rid of kernel/user space division and implements application/process protection by software using programing language resources. The other one is the MIT Exokernel [2], which provides a tiny kernel with almost no abstractions responsible only for safely multiplexing the hardware. Now, imagine a tiny kernel written in C, exposing Lua APIs, responsible mainly for multiplexing HW; and user processes implemented as separate Lua states running on the same address space, protected by language constructs.
I've just glanced at LOAD81 now.. pretty good job! thanks for sharing.. I noted your keyboard event handling (using SDL).. we have something very related to this in Lunatik (at the kernel level, of course) [1]. We've a kinda fun script that uses keyboard event handling to implement a "key locker" using Konami code [2].
The Arcan project[1] has pushed for this for a loooong time and doing some really interesting cutting edge things with it.
Depending on which set of Lua scripts it runs it fills a different role. The first set becomes the display server and window manager. It can then run itself recursively to provide graphical 'apps' (but also X11 ones, Wayland ones, ...).
I run the 'regular' desktop (stacking, tiling, ...) 'durden' right now, but I hope to switch to the more crazy dataflow/zui one (pipeworld[2]) or the VR one (safespaces[3]).
Then it has an additional 'curses like' one for TUIs and CLIs, 'arcan-tui' with a default shell Lash#Cat9[4]. Looking at their recent posts there also seem to be a network story including server-side processing, but I haven't had the time to play with out more than following the examples in the blog so can't say more about that.
EltaninOS[5] is trying to build a distribution around it.
However, giving you a short answer, we use Lua mainly because it's easy both to extend and to embed. It's implemented as an almost "freestanding" C library. Moreover, it has a considerable small footprint (~250 KB) in comparison to other scripting languages (e.g., Python has a few MB). Moreover, Lua has automatic memory management, fully isolated execution states, protected calls, among other features.
Maybe. Debatable. But the point was more that “replace all userspace [and kernelspace] with X” is the raison d'être of many Forths. So many classic Forth systems boot into a Forth environment, extended in Forth by the programmer-user. If that's what he's looking for, there's 55 years of Forth history to delve into.
Please feel welcome to join us on Matrix [1] as well.
[1] https://matrix.to/#/#lunatik:matrix.org