[HN Gopher] Lunatik: Lunatik is a framework for scripting the Li...
___________________________________________________________________
Lunatik: Lunatik is a framework for scripting the Linux kernel with
Lua
Author : todsacerdoti
Score : 140 points
Date : 2024-04-21 10:14 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| gnufx wrote:
| There was something like this using Scheme, maybe 20 years ago,
| but I don't remember any details and don't think I ever tried it.
|
| Edit: see http://www.abstractnonsense.com/schemix/
| febeling wrote:
| Interestingly, this project (Lunatik) started over 30 years ago
| in 1993.
|
| https://github.com/luainkernel/lunatik/graphs/contributors
| lneto wrote:
| this is because the repository is a Lua fork.. actually,
| Lunatik started in 2008 [1, 2].
|
| [1] https://sourceforge.net/projects/lunatik/files/ [2]
| https://www.maxwell.vrac.puc-
| rio.br/colecao.php?strSecao=res... (Portuguese only)
| febeling wrote:
| Ok, makes sense. Thanks for clarifying
| amelius wrote:
| Does this finally allow to write firewall rules in a sane and
| flexible language?
| lneto wrote:
| Please take a look at:
|
| [1] https://netdevconf.info/0x14/session.html?talk-linux-
| network... [2]
| https://netdevconf.info/0x17/sessions/talk/scripting-the-lin...
|
| I'm currently updating XDPLua and we might have a GSoC project
| on updating NFLua this year =)..
|
| [3] http://www.lua.inf.puc-rio.br/gsoc/ideas2024.html#lunatik-
| ne...
| ck45 wrote:
| Reminds me of Lua in the NetBSD kernel
|
| https://archive.fosdem.org/2013/schedule/event/lua_in_the_ne...
|
| Edit: It made it to HN front page today.
| lneto wrote:
| it's totally related.. we started with Lunatik in Linux
| actually then ported it to NetBSD..
|
| [1] https://www.netbsd.org/~lneto/dls14.pdf
| lneto wrote:
| a bit of history.. https://mail-index.netbsd.org/tech-
| kern/2010/10/05/msg008900...
| olejorgenb wrote:
| https://news.ycombinator.com/item?id=40086027
| lneto wrote:
| Happy to see this on HN =). Lunatik's main author here. AMA.
|
| Please feel welcome to join us on Matrix [1] as well.
|
| [1] https://matrix.to/#/#lunatik:matrix.org
| vaylian wrote:
| Does this use or relate to eBPF in any way?
| lneto wrote:
| It doesn't use eBPF but we can interoperate.. we have
| developed XDPLua for this as a GSoC project [1] and then
| published this work on Netdev 0x14 [2].
|
| [1] https://victornogueirario.github.io/xdplua/ [2]
| https://netdevconf.info/0x14/session.html?talk-linux-
| network...
|
| 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.
| bgm1975 wrote:
| What are some of the main use cases for this project?
| lneto wrote:
| the most explored use case is for scripting networking,
| please see:
|
| [1] https://legacy.netdevconf.info/0x14/session.html?talk-
| linux-... [2]
| https://netdevconf.info/0x17/sessions/talk/scripting-the-
| lin... [3] https://www.netbsd.org/~lneto/dls14.pdf [4]
| https://www.slideshare.net/eurobsdcon/lneto-npf-scripting [5]
| https://2018.eurobsdcon.org/static/slides/Fast,%20Flexible%2.
| ..
|
| 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].
|
| [6] https://web.stanford.edu/~ouster/cgi-
| bin/papers/scripting.pd... [7]
| https://drive.google.com/file/d/1TJ50IEbRXlBz-
| TxheGdkO-b4vLS... [8]
| https://youtu.be/-ufBgy044HI?si=IT4FOqeldA-jsg2r (Portuguese
| only)
|
| ZFS also has its own kernel Lua version (I'd love to unify
| them, BTW).
|
| Moreover, we have some simplified examples on our repository
| [9].
|
| [9] https://github.com/luainkernel/lunatik?tab=readme-ov-
| file#ex...
| robblbobbl wrote:
| Thank you for your efforts. This is a really good project. Kudos
| Solvency wrote:
| Weird miss to not call it Lunatix.
| lneto wrote:
| Perhaps when we have a fully scriptable operating system, we
| might call it Lunatix =).
| helpfulContrib wrote:
| This is so beautiful I could almost weep.
|
| 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!
|
| [1] = antirez' LOAD81, which I have long thought of as a fun way
| to build a new userspace front-end:
| https://github.com/antirez/LOAD81.git
| lneto wrote:
| 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.
|
| [1]
| https://pdos.csail.mit.edu/6.828/2008/readings/hunt07singula...
| [2]
| https://www.classes.cs.uchicago.edu/archive/2019/winter/3310...
|
| https://imgflip.com/i/8njfrr
| CodeCompost wrote:
| Why lua though?
| adastra22 wrote:
| Sounds like he needs to be introduced to Forth.
| lneto wrote:
| Please refer to Section 3 from [1], this was extensively
| discussed there.
|
| [1] https://www.netbsd.org/~lneto/dls14.pdf
|
| 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.
| lneto wrote:
| 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].
|
| [1] https://github.com/luainkernel/lunatik?tab=readme-ov-
| file#no... [2]
| https://github.com/luainkernel/lunatik?tab=readme-ov-file#ke...
| bhaney wrote:
| > Lunatik _does not_ support floating-point arithmetic
|
| Assuming there is one, what's the technical reason for this?
| cwillu wrote:
| > 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.
|
| https://www.kernel.org/doc/html/next/core-api/floating-point...
___________________________________________________________________
(page generated 2024-04-21 23:01 UTC)