Am 18.10.13 09:16, schrieb Alexander Nasonov: > Marc Balmer wrote: >> Module Name: src >> Committed By: mbalmer >> Date: Wed Oct 16 19:44:58 UTC 2013 >> >> Added Files: >> src/sys/modules/lua: Makefile assert.h ctype.h errno.h infinite.lua >> inttypes.h limits.h locale.h lua.c luaconf.h luavar.h math.h >> setjmp.h signal.h stdarg.h stddef.h stdio.h stdlib.h string.h >> test.lua >> >> Log Message: >> welcome lua(4), a devide driver that can create and control Lua states >> inside the kernel >> > > First of all, the code has been imported the wrong way as I stated in > the previous email. You should properly import Lua 5.2 to sys/external/ > and then apply local changes required to run it in kernel space.
This was not an import of Lua. The Lua sources already are in the tree. When we are ready to move from Lua 5.1 to Lua 5.2, Lua 5.2 will be imported to sys/external, as I already mentioned. > Second, lua device driver has a limited application. We need a generic > lua module. Your lua device driver can then use it. This is generic. The device driver is only there to control Lua states, load code into it, provide an ioctl interface to userland applications. When code in the kernel needs a Lua state, it does not use the lua(4) driver to create one (but the lua kernel module must be loaded, of course). > For example, if I want to generate bpf code when a user sends a filter > program to /dev/bpf* with Lua, I don't need a device driver. I need to > open a regular lua_State, load sljit module, run bfjit.lua script and > close the state afterwards. Which you can already do. I will have an example for that later. The function prototypes ar in sys/sys/lua.h, btw. > Also, I have a couple of small things. > > 1. Why do you use lua_ prefix for private functions? You get very close > to lua names: lua_reader vs lua_Reader of lua_require vs luaL_requiref. It does not really matter as long as the names don't clash. > 2. When you call lua_tostring() you often (or never???) don't check > whether it returns NULL. You can easily panic the kernel when you try > to print a table. I will look into this. The return values should be checked, for sure. Thanks for your feedback, Marc
