[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Moving Lua source codes
2013/10/21 Marc Balmer <marc%msys.ch@localhost>:
> 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?
Main Index |
Thread Index |