Re: [patch] put Lua standard libraries into the kernel

[Marc Balmer <marc%msys.ch@localhost>]

Am 28.11.13 23:19, schrieb Alexander Nasonov:

>> Yes, I understand this but I don't understand why to you need a special
>> control for it. It's your choice as a programmer to call that function
>> or not to call. Why do you need a special variable/syscal to control this?
> 
> Ok, I missed luactl(8) part I guess. I don't know your usecase but this
> remote orchestration of kernel Lua state from userspace sounds a bit
> dodgy to me.

luactl(8) is essential.  It is the command to load Lua code.  There are
two ways a Lua state can be created:

1) By a user using "luactl create ...".  This is when you want to run
scripts that access the kernel through bindings.

2) By software already in kernel, here "luactl load ..." is used to load
code.  An example application of this is a tty(4) line discipline
"lualdisc" that registers itself as a line discipline and creates a Lua
state.  The Lua code running in this state (loaded by a user) can then
register callbacks for the usual line discipline routines, so that Lua
functions get called for them.

Note that luactl(8) shows in its output whether a Lua state was created
by a user or software in the kernel.  In the latter case, luactl can not
be used to delete the state.

> Since you support 'luactl require' you can use it to load base libraries.
> There is no need for a boolean flag if you already have a more generic
> mechanism in place.

You miss the point.  The standard libraries are already compiled into
lua(4), they are not a freestanding kmod.  So "luactl require" can not
be used here.  The flag passed will merely indicate whether the
libraries are made available to a Lua state or not.

It will be interesting to see by how much memory the addition of the
standard libraries will grow lua(4).  lneto claims it does not grow at
all.  If it should, we can still move the standard libraries to a kmod.