Re: [ANN] Lunatik -- NetBSD kernel scripting with Lua (GSoC project

[Lourival Vieira Neto <lourival.neto@...>]

On Wed, Oct 6, 2010 at 6:23 AM, jean-Yves Migeon <jym@netbsd.org> wrote:
>
> On Tue, 5 Oct 2010 18:24:48 -0300, Lourival Vieira Neto
> <lourival.neto@gmail.com> wrote:
>> I'm glad to announce the results of my GSoC project this year [1].
>> We've created the support for scripting the NetBSD kernel with Lua,
>> which we called Lunatik and it is composed by a port of the Lua
>> interpreter to the kernel, a kernel programming interface for
>> extending subsystems and a user-space interface for loading user
>> scripts into the kernel. You can see more details on [2]. I am
>> currently working on the improvement of its implementation, on the
>> documentation and on the integration between Lunatik and other
>> subsystems, such as npf(9), to provide a real usage scenario.
>>
>> I'd like to take this space also to publicly thank Marc Balmer, for
>> his kind support; prof. Roberto Ierusalimschy, for his comprehension
>> and support; and NetBSD developers for their prompt help.
>>
>> [1]
>>
> http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/netbsd/t127230760748
>> [2] http://netbsd-soc.sourceforge.net/projects/luakern/
>>
>> Cheers,
>
> Heh, impressive :) Who would have imagined that NetBSD could end up with a
> "scripting" language inside kernel :o

=D

> Is there any sort of "limitation" between the "in-kernel" and a "userland"
> lua, when you adapted it to kernel's limited API?

Yes, there are some limitations. However, the only limitation on the
language _core_ is the numeric format. It was redefined from a
floating point type to an integer type (long long). We also provide
the entire Lua C API and part of the auxiliary library (we removed the
OS-dependent code, such as file handling and memory allocation).
Moreover, besides the language itself, we provide the table library
(and we are planning to port other libraries, such as string and
coroutine). If you want more details, please let me know.

> Taking your example with Fibonacci, this uses recursion. And recursion is
> bad(c) in a kernel. Does it affect lua? (this can get problematic when
> writing complex parsers, for example).

We did not change the Lua implementation itself, instead, we choose to
work around, putting some Lua dependencies into the kernel (such as
strncat and strcspn from string.h) and adapting in-kernel  some
functions/macros (such as setjmp(9)) to satisfy other dependencies.

I think that would be complex to disable recursion in Lua. I would
like to remember that the parsing job is done just once when the
script is loaded, then it is compiled into bytecode. Moreover, we are
planning to prevent this kind of problem by restricting the access for
loading scripts into the kernel.

> This is definitely interesting anyway; thanks for your work!

Thanks..

> Cheers,
>
> --
> Jean-Yves Migeon
> jym@NetBSD.org
>

Cheers,
--
Lourival Vieira Neto