Re: [patch] put Lua standard libraries into the kernel
On 29 Nov 2013 14:11, "Lourival Vieira Neto"
wrote:
>
> On Fri, Nov 29, 2013 at 10:03 AM, Marc Balmer wrote:
> > Am 29.11.13 12:38, schrieb Lourival Vieira Neto:
> >>> 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.
> >>
> >> I just double checked now (using nm to confirm). In fact, I was
> >> commenting the wrong portion of the Makefile to test. Sorry about that
> >> =(. Here is the result in amd64: 240K with stdlibs and auxlib, 166K
> >> with only auxlib and 154K solo. Anyway, I still think that is 86K is
> >> not that much to have things like {base, string, table}lib. However,
> >> though I think stdlibs could be in another kmod, I think that is not a
> >> good idea to have auxlib in another one. Lua auxlib is just an
> >> extension of the Lua C API and 12K is really a fair price to have a
> >> more complete Lua library in kernel, IMO.
> >
> > We could for now just go ahead, put auxlib and the stdlibs in lua(4) as
> > foreseen, and when the need arises, we can still factor out the stdlibs
> > to their own kmod.
>
> Agreed. Anyone opposes?
>
Sounds fine.
Re: [patch] put Lua standard libraries into the kernel
On Fri, Nov 29, 2013 at 10:03 AM, Marc Balmer wrote:
> Am 29.11.13 12:38, schrieb Lourival Vieira Neto:
>>> 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.
>>
>> I just double checked now (using nm to confirm). In fact, I was
>> commenting the wrong portion of the Makefile to test. Sorry about that
>> =(. Here is the result in amd64: 240K with stdlibs and auxlib, 166K
>> with only auxlib and 154K solo. Anyway, I still think that is 86K is
>> not that much to have things like {base, string, table}lib. However,
>> though I think stdlibs could be in another kmod, I think that is not a
>> good idea to have auxlib in another one. Lua auxlib is just an
>> extension of the Lua C API and 12K is really a fair price to have a
>> more complete Lua library in kernel, IMO.
>
> We could for now just go ahead, put auxlib and the stdlibs in lua(4) as
> foreseen, and when the need arises, we can still factor out the stdlibs
> to their own kmod.
Agreed. Anyone opposes?
Regards,
--
Lourival Vieira Neto
Re: [patch] put Lua standard libraries into the kernel
Am 29.11.13 12:38, schrieb Lourival Vieira Neto:
>> 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.
>
> I just double checked now (using nm to confirm). In fact, I was
> commenting the wrong portion of the Makefile to test. Sorry about that
> =(. Here is the result in amd64: 240K with stdlibs and auxlib, 166K
> with only auxlib and 154K solo. Anyway, I still think that is 86K is
> not that much to have things like {base, string, table}lib. However,
> though I think stdlibs could be in another kmod, I think that is not a
> good idea to have auxlib in another one. Lua auxlib is just an
> extension of the Lua C API and 12K is really a fair price to have a
> more complete Lua library in kernel, IMO.
We could for now just go ahead, put auxlib and the stdlibs in lua(4) as
foreseen, and when the need arises, we can still factor out the stdlibs
to their own kmod.
Re: [patch] put Lua standard libraries into the kernel
> 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.
I just double checked now (using nm to confirm). In fact, I was
commenting the wrong portion of the Makefile to test. Sorry about that
=(. Here is the result in amd64: 240K with stdlibs and auxlib, 166K
with only auxlib and 154K solo. Anyway, I still think that is 86K is
not that much to have things like {base, string, table}lib. However,
though I think stdlibs could be in another kmod, I think that is not a
good idea to have auxlib in another one. Lua auxlib is just an
extension of the Lua C API and 12K is really a fair price to have a
more complete Lua library in kernel, IMO.
Regards,
--
Lourival Vieira Neto
Re: [patch] put Lua standard libraries into the kernel
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.
Re: [patch] put Lua standard libraries into the kernel
Am 28.11.13 22:52, schrieb Lourival Vieira Neto: >> If the standard libraries should be a separate kmod or if the code >> should just reside in lua(4) is another question. > > I really see no reason to put it in another kmod. Moreover, following > the user-space analogy argument, liblua is linked altogether. I agree in this case, since it is the libraries that usually ship with Lua, users might expect them to be present. Othe than that, don't be shy to create another kmod if you need a library, kmods are the only way to provide libraries to lua(4). of course we must take to not let the number explode.
Re: [patch] put Lua standard libraries into the kernel
fine by me Freundliche Grüsse, Marc Balmer -- Marc Balmer micro systems, Landstrasse 66, CH-5073 Gipf-Oberfrick Tel.: +41 62 871 45 65, http://www.msys.ch/ arcapos(r) Kassensystem: http://www.arcapos.ch/ Am 28.11.2013 um 22:52 schrieb Lourival Vieira Neto : >> If the standard libraries should be a separate kmod or if the code >> should just reside in lua(4) is another question. > > I really see no reason to put it in another kmod. Moreover, following > the user-space analogy argument, liblua is linked altogether. > > Regards, > -- > Lourival Vieira Neto
Re: [patch] put Lua standard libraries into the kernel
Alexander Nasonov wrote: > 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. 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. Alex
Re: [patch] put Lua standard libraries into the kernel
Marc Balmer wrote: > If they are, then of course the standard functions like luaL_openlibs() > are used. So this not about a replacement mechanism for > luaL_openlibs(), but to control whether luaL_openlibs() is called or not. 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? Alex
Re: [patch] put Lua standard libraries into the kernel
> If the standard libraries should be a separate kmod or if the code > should just reside in lua(4) is another question. I really see no reason to put it in another kmod. Moreover, following the user-space analogy argument, liblua is linked altogether. Regards, -- Lourival Vieira Neto
Re: [patch] put Lua standard libraries into the kernel
Am 28.11.13 22:17, schrieb Alexander Nasonov: > Marc Balmer wrote: >> Am 27.11.13 22:23, schrieb Martin Husemann: >> >>> Can't it be a per-state option, passed by luactl when creating the state? >> >> That is actually an excellent idea. So what should be the default, >> stdlibs enabled or not enabled? > > I'm a bit late to join the conversation but I wanted to emphasize one > quite important thing: > > Please keep look & feel of plain userspace Lua even in the kernel space. > > If you look at NetBSD C code in the kernel, and compare it with some > other's OS kernel code, NetBSD code will likely look more natural. > I hope that one day we can say the same about Lua code in NetBSD. > > There is no need to invent new things if they're already provided by the > languange. > > So, I don't think we need a special sysctl to control loading of standard > libraries. Lua already gives you luaL_openlibs() and luaL_requiref(). Jzst to clarify what the discussion was about: The sysctl variable, or flag passed to lua(4) when using luactl(8) to create a new Lua state, only indicates whether the standard libraries should be provided to the newly created state or not. If they are, then of course the standard functions like luaL_openlibs() are used. So this not about a replacement mechanism for luaL_openlibs(), but to control whether luaL_openlibs() is called or not. If the standard libraries should be a separate kmod or if the code should just reside in lua(4) is another question.
Re: [patch] put Lua standard libraries into the kernel
Marc Balmer wrote: > Am 27.11.13 22:23, schrieb Martin Husemann: > > > Can't it be a per-state option, passed by luactl when creating the state? > > That is actually an excellent idea. So what should be the default, > stdlibs enabled or not enabled? I'm a bit late to join the conversation but I wanted to emphasize one quite important thing: Please keep look & feel of plain userspace Lua even in the kernel space. If you look at NetBSD C code in the kernel, and compare it with some other's OS kernel code, NetBSD code will likely look more natural. I hope that one day we can say the same about Lua code in NetBSD. There is no need to invent new things if they're already provided by the languange. So, I don't think we need a special sysctl to control loading of standard libraries. Lua already gives you luaL_openlibs() and luaL_requiref(). Alex
Re: [patch] put Lua standard libraries into the kernel
On Thu, Nov 28, 2013 at 6:13 AM, Marc Balmer wrote: > Am 27.11.13 22:23, schrieb Martin Husemann: > >> Can't it be a per-state option, passed by luactl when creating the state? > > That is actually an excellent idea. So what should be the default, > stdlibs enabled or not enabled? IMO, it should be disabled by default. Thus, it would mimic the Lua library behavior. Where Lua states are created empty and if you want to use stdlibs, you must explicitly load it (e.g., calling luaL_openlibs()). Regards, -- Lourival Vieira Neto
Re: [patch] put Lua standard libraries into the kernel
Am 27.11.13 22:23, schrieb Martin Husemann: > Can't it be a per-state option, passed by luactl when creating the state? That is actually an excellent idea. So what should be the default, stdlibs enabled or not enabled? - Marc
Re: [patch] put Lua standard libraries into the kernel
On Wed, Nov 27, 2013 at 7:23 PM, Martin Husemann wrote: > Can't it be a per-state option, passed by luactl when creating the state? I think this is a better option. Regards, -- Lourival Vieira Neto
Re: [patch] put Lua standard libraries into the kernel
On Wed, Nov 27, 2013 at 6:15 PM, dieter roelants wrote: > On Tue, 26 Nov 2013 12:50:16 +0100 > Marc Balmer wrote: > >> My suggestion is this: >> >> Build with lauxlib and also build the standard libraries >> Create a new sysctl kern.lua.stdlib, set to one by default >> If a new state is created in lua(4), run lua_openlib(...) on that state >> if kern.lua.stdlib is set to a vaue != 0 >> >> So by default a kernel Lua state would then have the stdlibs available, >> much you have them available when running lua(1). > > Maybe it's just me, but it seems strange to have this depend on a > (global) sysctl. I assume you have a reason for being able to disable > it. But if you then want to run other lua code that needs the stdlibs, > it will be enabled for your original code as well. Did I misunderstand? Yes, you're right. Regards, -- Lourival Vieira Neto
Re: [patch] put Lua standard libraries into the kernel
Can't it be a per-state option, passed by luactl when creating the state? Martin
Re: [patch] put Lua standard libraries into the kernel
On Tue, 26 Nov 2013 12:50:16 +0100 Marc Balmer wrote: > My suggestion is this: > > Build with lauxlib and also build the standard libraries > Create a new sysctl kern.lua.stdlib, set to one by default > If a new state is created in lua(4), run lua_openlib(...) on that state > if kern.lua.stdlib is set to a vaue != 0 > > So by default a kernel Lua state would then have the stdlibs available, > much you have them available when running lua(1). Maybe it's just me, but it seems strange to have this depend on a (global) sysctl. I assume you have a reason for being able to disable it. But if you then want to run other lua code that needs the stdlibs, it will be enabled for your original code as well. Did I misunderstand? kind regards dieter
Re: [patch] put Lua standard libraries into the kernel
On Tue, Nov 26, 2013 at 9:50 AM, Marc Balmer wrote: > Am 26.11.13 12:13, schrieb Lourival Vieira Neto: >> Hi Marc, >> >> On Tue, Nov 26, 2013 at 6:18 AM, Marc Balmer wrote: >>> Am 26.11.13 02:50, schrieb Lourival Vieira Neto: Hi Folks, Here is a patch that puts some Lua standard libraries into the kernel: - Auxiliary library (C API); - Base library; - String library; - Table library. >>> >>> In the kernel, Lua states are created empty _on purpose_. So the Lua >>> standard library should be a module (or modules) in kernel space. >> >> Why? >> >> Note, the Lua states still empty, but, with this patch, you can call >> luaL_openlibs(). >> >>> Whether all standard libraries should be one module, or rather multiple >>> kernel modules, is to be discussed. >> >> Let's discuss then =). > > My suggestion is this: > > Build with lauxlib and also build the standard libraries > Create a new sysctl kern.lua.stdlib, set to one by default > If a new state is created in lua(4), run lua_openlib(...) on that state > if kern.lua.stdlib is set to a vaue != 0 > > So by default a kernel Lua state would then have the stdlibs available, > much you have them available when running lua(1). It is just fine for me =). Regards, -- Lourival Vieira Neto
Re: [patch] put Lua standard libraries into the kernel
Am 26.11.13 12:13, schrieb Lourival Vieira Neto: > Hi Marc, > > On Tue, Nov 26, 2013 at 6:18 AM, Marc Balmer wrote: >> Am 26.11.13 02:50, schrieb Lourival Vieira Neto: >>> Hi Folks, >>> >>> Here is a patch that puts some Lua standard libraries into the kernel: >>> >>> - Auxiliary library (C API); >>> - Base library; >>> - String library; >>> - Table library. >> >> In the kernel, Lua states are created empty _on purpose_. So the Lua >> standard library should be a module (or modules) in kernel space. > > Why? > > Note, the Lua states still empty, but, with this patch, you can call > luaL_openlibs(). > >> Whether all standard libraries should be one module, or rather multiple >> kernel modules, is to be discussed. > > Let's discuss then =). My suggestion is this: Build with lauxlib and also build the standard libraries Create a new sysctl kern.lua.stdlib, set to one by default If a new state is created in lua(4), run lua_openlib(...) on that state if kern.lua.stdlib is set to a vaue != 0 So by default a kernel Lua state would then have the stdlibs available, much you have them available when running lua(1). > >> But please don't load the automatically. > > Do you mean 'don't link Lua stdlib with Lua'? What is the reason? > > Regards, >
Re: [patch] put Lua standard libraries into the kernel
Hi Marc, On Tue, Nov 26, 2013 at 6:18 AM, Marc Balmer wrote: > Am 26.11.13 02:50, schrieb Lourival Vieira Neto: >> Hi Folks, >> >> Here is a patch that puts some Lua standard libraries into the kernel: >> >> - Auxiliary library (C API); >> - Base library; >> - String library; >> - Table library. > > In the kernel, Lua states are created empty _on purpose_. So the Lua > standard library should be a module (or modules) in kernel space. Why? Note, the Lua states still empty, but, with this patch, you can call luaL_openlibs(). > Whether all standard libraries should be one module, or rather multiple > kernel modules, is to be discussed. Let's discuss then =). > But please don't load the automatically. Do you mean 'don't link Lua stdlib with Lua'? What is the reason? Regards, -- Lourival Vieira Neto
Re: [patch] put Lua standard libraries into the kernel
Am 26.11.13 02:50, schrieb Lourival Vieira Neto: > Hi Folks, > > Here is a patch that puts some Lua standard libraries into the kernel: > > - Auxiliary library (C API); > - Base library; > - String library; > - Table library. In the kernel, Lua states are created empty _on purpose_. So the Lua standard library should be a module (or modules) in kernel space. Whether all standard libraries should be one module, or rather multiple kernel modules, is to be discussed. But please don't load the automatically.
Re: [patch] put Lua standard libraries into the kernel
On Tue, Nov 26, 2013 at 12:08 AM, Paul Goyette wrote: > Hopefully, this actually puts the libraries into the _optional_ lua kernel > module, and not into the kernel itself? > > :) heh.. course.. s/kernel/Lua kernel module/ =) Regards, -- Lourival Vieira Neto
Re: [patch] put Lua standard libraries into the kernel
Hopefully, this actually puts the libraries into the _optional_ lua kernel module, and not into the kernel itself? :) On Mon, 25 Nov 2013, Lourival Vieira Neto wrote: Hi Folks, Here is a patch that puts some Lua standard libraries into the kernel: - Auxiliary library (C API); - Base library; - String library; - Table library. Regards, -- Lourival Vieira Neto !DSPAM:5293fe9466506470520695! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
[patch] put Lua standard libraries into the kernel
Hi Folks, Here is a patch that puts some Lua standard libraries into the kernel: - Auxiliary library (C API); - Base library; - String library; - Table library. Regards, -- Lourival Vieira Neto lua_kernel_stdlib.patch Description: Binary data
