On Wed, Jun 17, 2015 at 12:17 PM, Andrew Cagney <andrew.cag...@gmail.com> wrote: > 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.
My point here isn't that you should use lua(4) as a loadable kernel module. Actually, I'm trying to answer your original question: yes, lua(4) is also a library. It defines an API to use Lua in-kernel. (See sys/lua.h.) And npf_lua uses lua(4) in that way. (I think you should take a look at Section 4 and the "extending vs embedding" discussion at Section 2 of [3].) [3] http://www.netbsd.org/~lneto/dls14.pdf >>>>> (...) >>>>> 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? Perhaps =). > 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. I was suggesting you to link lua(4) statically in the kernel, instead of reimplementig part of lua(4) in DDB. I never did that, but it should be as easy as any other module/driver linked statically in the kernel. >>> (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 I don't know much about DDB; but if you have access to raw memory, you can use Luadata to access it from Lua as an array of bytes, bit fields and structured data in a straightforward way. >>>> 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 Thanks! >> 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. Nice =). > BTW, is lua's testsuite run against the in-kernel lua module? Guilherme Salazar (cc'ed) is porting this as a GSoC project =). (See http://www.lua.inf.puc-rio.br/gsoc/ideas2015.html#kerneltest.) -- Lourival Vieira Neto