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.
