On Wed, Oct 6, 2010 at 6:23 AM, jean-Yves Migeon <[email protected]> wrote: > > On Tue, 5 Oct 2010 18:24:48 -0300, Lourival Vieira Neto > <[email protected]> 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 > [email protected] > Cheers, -- Lourival Vieira Neto
