tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Moving Lua source codes

2013/10/21 Marc Balmer <>:
> Am 20.10.13 22:02, schrieb Artem Falcon:
> [...]
>> Ok, here i have a clean diff. Sorry for the attach instead of inline.
>> By the way, do you want to move from malloc(9) to kmem(9) as
>> recommended? I may provide a draft version, if you're interested.
> Thank you for your diff, I will look at it in a few days (I am not at my
> office the next few days, being abroad for @work stuff).
> As for malloc(9) switching to kmem(9), I don't want to do that because
> of the way how Lua allocates memory.  An allocator function is called
> with some number of bytes to be allocated.  We have no control over how
> many bytes it wants us to allocate.  If using kmem(9), we would have to
> keep track of this allocations, since kmem_free() takes as a second
> argument the number of bytes to free.  kmem(9) is not very usable here
> imo, since we have to pass the number of bytes to free.

Now i see. Thanks for clearing it out.

> btw, you can also CC tech-kern@, no need to keep this discussion private...

Doing w/o a diff, i don't have a sane mail environment now to send it inline.

There's few more things.
First: you forgot to add MODULE_CLASS_LUA_BINDING to a
Second: kernel side Lua will reject to load bytecode produced by luac cause
the first built FPless. A simple solution is to build luac and liblua feeded
with FPless luaconf.h and put them under different names. Maybe a more
elegant solution is possible?

Home | Main Index | Thread Index | Old Index