On 17 June 2015 at 00:48, Lourival Vieira Neto <lourival.n...@gmail.com> wrote: >>>> Is the kernel's version of Lua available as a library? >>> >>> You can use it as a regular kernel module. Take a look at this patch >>> [1] which adds Lua to NPF, as an example. >> >> thanks, I'd looked briefly at the lua et.al. modules. > > Please notice that the modules already present in base work like Lua > libraries (that is, they are called by Lua) and npf_lua works like a > host program (calling Lua). I think the last is more appropriate to > your use case.
I'm not so sure. If I create a module and then have that "bind" to ddb and lua then yes. However, if I try to make this work before modules have even been loaded then, no. >>>> (...) >>>> to sys/ddb/files.ddb is not the best way to link Lua into DDB >> >> My understanding of this general approach is that it would make DDB >> dependent on a [possibly loadable] kernel module? Or perhaps I can >> add a "lua" pseudo device and start calling the underlying library >> directly? >> >> To me an in-kernel debugger needs to be both largely standalone and >> callable from every very early in the boot process. For instance, >> just after the serial console's initialized and showing signs of >> working. > > Then, I think you should just compile lua(4) statically instead of > reimplementing it tied to DDB. I'm not sure I'm following. Perhaps we're agreeing? My lua binding needs access to DDB's code, and the DDB code needs access to my Lua instance. This is why I added the lua files to sys/ddb/files.ddb. It seemed tedious. I suspect it would be easier to create lua.a (built for the kernel) and have both the lua module and (optionally) ddb+kernel link against it. >> (This is also why I need to change my hack so that it uses a static >> buffer for Lua's heap; using the kernel to allocate memory when >> debugging the kernel's memory allocator doesn't tend to work very well >> :-) > > Then, you should just call klua_newstate(9) passing your custom > allocator =). BTW, perhaps Luadata [2] can help you to hack memory. > > [2] https://github.com/lneto/luadata/ Yes. For the moment I've a really simple binding: lua> m=setmetatable({},{ __index=function(table,addr) return db_peek(addr); end}) lua> print(m[db_debug_buf+1],m[db_debug_buf+2],m[db_debug_buf+3]) 69 76 70 >>> What's your plan for DDB+Lua? =) >> >> literally, to see what happens when you put lua and dwarf in a kernel >> (see BSDCan) > > Pretty cool! Are the slides publicly available in somewhere? (I couldn't > find.) They should appear shortly. I've also put them here https://bitbucket.org/cagney/netbsd/downloads > Moreover, I notice that you've found a bug on the usage of snprintf. > Was this the only one? Please report it next time! =) That was the only problem I found, which is impressive. BTW, is lua's testsuite run against the in-kernel lua module? Andrew
