Re: CVS commit: src/sys/modules/lua
apb@ wrote: > On Fri, 18 Oct 2013, Marc Balmer wrote: > >> Did you get core approval for this? The public discussion is > >> still ongoing, and still lacking in evidence, and there has > >> been no public statement by core as far as I am aware, nor did > >> any members of core I asked have any recollection of approving > >> this. Please don't steamroll over public discussions like > >> this. > > Just for the record, yes, I got core's approval. > > Could you tell us approximately when you got that approval? It > wasn't in the past two years while I have been a member of core. Lua was initially imported ~three years ago http://www.netbsd.org/changes/changes-6.0.html#lua%281%29 as a result of GSoC 2010: http://mail-index.netbsd.org/tech-kern/2010/10/05/msg008900.html http://netbsd-soc.sourceforge.net/projects/luakern/ IMO, importing lua is a good material for advocacy (there are so many mentions about it on Twitter/Facebook etc.) while it took too long.. --- Izumi Tsutsui
Re: CVS commit: src/sys/modules/lua
On Fri, 18 Oct 2013, Marc Balmer wrote: Did you get core approval for this? The public discussion is still ongoing, and still lacking in evidence, and there has been no public statement by core as far as I am aware, nor did any members of core I asked have any recollection of approving this. Please don't steamroll over public discussions like this. Just for the record, yes, I got core's approval. Could you tell us approximately when you got that approval? It wasn't in the past two years while I have been a member of core. --apb (Alan Barrett)
Re: CVS commit: xsrc/external/mit/xdm/dist/xdm
On Fri, 18 Oct 2013, Jukka Ruohonen wrote: Print time_t values by casting to intmax_t and using "%ji" format. Wouldn't the "right" way be PRIdMAX from inttypes(3)? Anyways, for curiosity: is there actually a portable way across operating systems to deal with this? The "j" modifier is defined in the C99 standard, and that's good enough for me. PRIdMAX would also work, but is more verbose. I suppose some operating systems might exist where "%jd" doesn't work but "%"PRIdMAX does work, and if this was the xorg project instead of the NetBSD project then I might care about that. --apb (Alan Barrett)
Re: CVS commit: xsrc/external/mit/xdm/dist/xdm
On Fri, 18 Oct 2013, Christos Zoulas wrote: The result from strlen() has type size_t, so print it with "%zd" format. %zu is correct. Fixed, thanks.
Re: CVS commit: xsrc/external/mit/xdm/dist/xdm
On Fri, Oct 18, 2013 at 03:59:38PM +, Alan Barrett wrote: > Module Name: xsrc > Committed By: apb > Date: Fri Oct 18 15:59:38 UTC 2013 > > Modified Files: > xsrc/external/mit/xdm/dist/xdm: dm.c > > Log Message: > Print time_t values by casting to intmax_t and using "%ji" format. Wouldn't the "right" way be PRIdMAX from inttypes(3)? Anyways, for curiosity: is there actually a portable way across operating systems to deal with this? - Jukka.
Re: CVS commit: src/sys/modules/lua
Am 18.10.13 19:13, schrieb Alexander Nasonov: > Marc Balmer wrote: >> This was not an import of Lua. The Lua sources already are in the tree. >> When we are ready to move from Lua 5.1 to Lua 5.2, Lua 5.2 will be >> imported to sys/external, as I already mentioned. > > In this case, kernel changes should have been added to 5.1 source and > later ported to 5.2 code. I don't understand you here. The Lua codes wher imported unaltered. > >>> For example, if I want to generate bpf code when a user sends a filter >>> program to /dev/bpf* with Lua, I don't need a device driver. I need to >>> open a regular lua_State, load sljit module, run bfjit.lua script and >>> close the state afterwards. >> >> Which you can already do. I will have an example for that later. The >> function prototypes ar in sys/sys/lua.h, btw. > > ok > >> It does not really matter as long as the names don't clash. > > It potentially makes upgrading to a newer version of Lua more difficult > because your private names may conflict with the new version of Lua API. That would be spotted immediately when doing a test build. > It also harder to read code. That is only a matter of taste, imo.
Re: CVS commit: src/sys/modules/lua
Marc Balmer wrote: > This was not an import of Lua. The Lua sources already are in the tree. > When we are ready to move from Lua 5.1 to Lua 5.2, Lua 5.2 will be > imported to sys/external, as I already mentioned. In this case, kernel changes should have been added to 5.1 source and later ported to 5.2 code. > > For example, if I want to generate bpf code when a user sends a filter > > program to /dev/bpf* with Lua, I don't need a device driver. I need to > > open a regular lua_State, load sljit module, run bfjit.lua script and > > close the state afterwards. > > Which you can already do. I will have an example for that later. The > function prototypes ar in sys/sys/lua.h, btw. ok > It does not really matter as long as the names don't clash. It potentially makes upgrading to a newer version of Lua more difficult because your private names may conflict with the new version of Lua API. It also harder to read code. Alex
Re: CVS commit: xsrc/external/mit/xdm/dist/xdm
In article <20131018163140.a391...@cvs.netbsd.org>, Alan Barrett wrote: >-=-=-=-=-=- > >Module Name: xsrc >Committed By: apb >Date: Fri Oct 18 16:31:40 UTC 2013 > >Modified Files: > xsrc/external/mit/xdm/dist/xdm: xdmauth.c > >Log Message: >The result from strlen() has type size_t, so print it with "%zd" format. %zu is correct. christos
Re: CVS commit: src/sys/modules/lua
Am 18.10.13 14:24, schrieb Taylor R Campbell: >From: "Marc Balmer" >Date: Wed, 16 Oct 2013 19:44:58 + > >welcome lua(4), a devide driver that can create and control Lua states > inside >the kernel > > Did you get core approval for this? The public discussion is still > ongoing, and still lacking in evidence, and there has been no public > statement by core as far as I am aware, nor did any members of core I > asked have any recollection of approving this. Please don't steamroll > over public discussions like this. Just for the record, yes, I got core's approval.
Re: CVS commit: src/sys/modules/lua
From: "Marc Balmer" Date: Wed, 16 Oct 2013 19:44:58 + welcome lua(4), a devide driver that can create and control Lua states inside the kernel Did you get core approval for this? The public discussion is still ongoing, and still lacking in evidence, and there has been no public statement by core as far as I am aware, nor did any members of core I asked have any recollection of approving this. Please don't steamroll over public discussions like this.
Re: CVS commit: src/sys/modules/lua
On Fri, Oct 18, 2013 at 08:16:32AM +0100, Alexander Nasonov wrote: > First of all, the code has been imported the wrong way as I stated in > the previous email. You should properly import Lua 5.2 to sys/external/ > and then apply local changes required to run it in kernel space. I agree. Already for the sake of consistency and sanity; if one looks at at sys/modules, there is no existing code in it. On Fri, Oct 18, 2013 at 09:29:44AM +0200, Marc Balmer wrote: > This was not an import of Lua. The Lua sources already are in the tree. > When we are ready to move from Lua 5.1 to Lua 5.2, Lua 5.2 will be > imported to sys/external, as I already mentioned. Why not do things right the first time? Sounds a like a recipe for a mess. - Jukka.
re: CVS commit: src/external/mit/xorg/lib
> Module Name: src > Committed By: riz > Date: Fri Oct 18 01:12:00 UTC 2013 > > Modified Files: > src/external/mit/xorg/lib/libX11: Makefile.libx11 > src/external/mit/xorg/lib/libXi: Makefile > > Log Message: > Before testing the value of HAVE_GCC, test if it's defined. this probably should make sure to include then?
Re: CVS commit: src/sys/modules/lua
Am 18.10.13 09:16, schrieb Alexander Nasonov: > Marc Balmer wrote: >> Module Name: src >> Committed By:mbalmer >> Date:Wed Oct 16 19:44:58 UTC 2013 >> >> Added Files: >> src/sys/modules/lua: Makefile assert.h ctype.h errno.h infinite.lua >> inttypes.h limits.h locale.h lua.c luaconf.h luavar.h math.h >> setjmp.h signal.h stdarg.h stddef.h stdio.h stdlib.h string.h >> test.lua >> >> Log Message: >> welcome lua(4), a devide driver that can create and control Lua states >> inside the kernel >> > > First of all, the code has been imported the wrong way as I stated in > the previous email. You should properly import Lua 5.2 to sys/external/ > and then apply local changes required to run it in kernel space. This was not an import of Lua. The Lua sources already are in the tree. When we are ready to move from Lua 5.1 to Lua 5.2, Lua 5.2 will be imported to sys/external, as I already mentioned. > Second, lua device driver has a limited application. We need a generic > lua module. Your lua device driver can then use it. This is generic. The device driver is only there to control Lua states, load code into it, provide an ioctl interface to userland applications. When code in the kernel needs a Lua state, it does not use the lua(4) driver to create one (but the lua kernel module must be loaded, of course). > For example, if I want to generate bpf code when a user sends a filter > program to /dev/bpf* with Lua, I don't need a device driver. I need to > open a regular lua_State, load sljit module, run bfjit.lua script and > close the state afterwards. Which you can already do. I will have an example for that later. The function prototypes ar in sys/sys/lua.h, btw. > Also, I have a couple of small things. > > 1. Why do you use lua_ prefix for private functions? You get very close > to lua names: lua_reader vs lua_Reader of lua_require vs luaL_requiref. It does not really matter as long as the names don't clash. > 2. When you call lua_tostring() you often (or never???) don't check > whether it returns NULL. You can easily panic the kernel when you try > to print a table. I will look into this. The return values should be checked, for sure. Thanks for your feedback, Marc
Re: CVS commit: src/sys/modules/lua
Marc Balmer wrote: > Module Name: src > Committed By: mbalmer > Date: Wed Oct 16 19:44:58 UTC 2013 > > Added Files: > src/sys/modules/lua: Makefile assert.h ctype.h errno.h infinite.lua > inttypes.h limits.h locale.h lua.c luaconf.h luavar.h math.h > setjmp.h signal.h stdarg.h stddef.h stdio.h stdlib.h string.h > test.lua > > Log Message: > welcome lua(4), a devide driver that can create and control Lua states inside > the kernel > First of all, the code has been imported the wrong way as I stated in the previous email. You should properly import Lua 5.2 to sys/external/ and then apply local changes required to run it in kernel space. Second, lua device driver has a limited application. We need a generic lua module. Your lua device driver can then use it. For example, if I want to generate bpf code when a user sends a filter program to /dev/bpf* with Lua, I don't need a device driver. I need to open a regular lua_State, load sljit module, run bfjit.lua script and close the state afterwards. Also, I have a couple of small things. 1. Why do you use lua_ prefix for private functions? You get very close to lua names: lua_reader vs lua_Reader of lua_require vs luaL_requiref. 2. When you call lua_tostring() you often (or never???) don't check whether it returns NULL. You can easily panic the kernel when you try to print a table. Alex
