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