Re: lua kernel library?

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On 17 June 2015 at 00:48, Lourival Vieira Neto <lourival.neto%gmail.com@localhost> 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