Re: lua kernel library?

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

>>> 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.

>>> (...)
>>> 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.

> (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/

>> 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.)

Moreover, I notice that you've found a bug on the usage of snprintf.
Was this the only one? Please report it next time! =)

-- 
Lourival Vieira Neto