Re: lua kernel library?

[Lourival Vieira Neto <lourival.neto%gmail.com@localhost>]

On Wed, Jun 17, 2015 at 12:17 PM, Andrew Cagney <andrew.cagney%gmail.com@localhost> wrote:
> 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.

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