script(2) [was: [CFT/review] new sendfile(2)]

[Walt Ford]

On Mon, Sep 01, 2014 at 09:34:05PM +0000, Poul-Henning Kamp wrote:
> In message <5404D1B8.9010006 at mu.org>, Alfred Perlstein writes:
>>> In message <5403B13C.60008 at freebsd.org>, Alfred Perlstein writes:
>>>
>>>> Lua at the syscall level makes sense. :)
>>> I doubt it.
>>>
>>> We're looking at high performance stuff and we don't want a silly
>>> parser and string processing involved.
>>>
>>Would it really matter?  Lua is bytecode, [...]
> 
> I though you wanted the interpreter in the kernel.
> 
> If it's only the executor, then ... maybe... 
> 
> We'd need to do a serious audit of the lua bytecode first...

I've been sort of working on a Lua-based FreeBSD for years in my spare
time just because I love both so much.  I could be wrong, but I think
making use of Lua in-kernel would require modifying the interpreter to
include the kernel's idea of locks, mutexes, memory barriers, and threads.
In Lua, threads and their safety must be written by end-users last I knew,
but I don't follow Lua development closely.

At least in my latest work, trying to replace init_main.c and mi_startup()
with a Lua script, all of that is necessary.  Really, I'd even need the
interpreter to be aware of the FreeBSD scheduler for a Lua-based mi_startup
to be workable.

I've got a lot of Lua bits and pieces in userland utilities, libraries,
and now init_main.c is in boot/ but none of it works yet.  I have visions
of a FreeBSD that unboot backwards to reload subsystems, but I'm not
close.

-- 
Walt