3 ms·

I won't address your general point, because, I never wrote any drivers, but the following may appease some of your concerns. Changing the number type in Lua is

by pygy_ 13y ago

I won't address your general point, because, I never wrote any drivers, but the following may appease some of your concerns. Changing the number type in Lua is only a few #DEFINEs away. See http://www.lua.org/source/5.2/luaconf.h.html#LUA_NUMBER http://www.lua.org/source/5.2/luaconf.h.html#LUA_NUMBER and the comment above it. Regarding the lack of infix bitwise operators: usually, the functions are cached in locals. It is not as readable as C, but less bulky than what you wrote: local band, bnot = bit32.band, bit32.bnot function avi_unset(addr, val) local v = assert(devmem.read32(addr)) v = band(bnot(v), val) avi_write(addr, v) end If it became apparent that infix operators were needed, adding them to the VM is trivial (There's a power patch for Lua 5.1, and a patch for Lua 5.2 was recently posted in the mailing list). If you want to use the stock VM, you can still use a preprocessor (which makes things a bit more cumbersome).

simias 13y ago
I remember looking at this LUA_NUMBER but I wondered if changing it to an integer type would break something, it's not explicitly mentioned that you can use an integer type there. I'm sure it can be done but it still means that your custom lua will behave a bit differently than the "stock" lua (especially when it comes to things like roundings and overflows). That might be a bit problematic if you prototype your code on one and then attempt to run on the other. As for your improved code I didn't know I could do that, it does look much better indeed. Again, maybe I'm just nitpicking but my main point was that lua, scripting language or not, just didn't seem better suited than C at writing device drivers. That being said, having a good in-kernel REPL would revolutionize kernel hacking, but it seems very hard to do right. Lots of kernel code is very timing-sensitive and you can't afford to wait for user input when you're in a critical path. Just look at the difficulty to implement proper kernel debugging to get a taste of it. The thing is, the NetBSD people know that and more and yet they decided to go with it. I would be very interested to know their objective/motivation. I googled a bit around and found this: http://netbsd-soc.sourceforge.net/projects/luakern/ http://netbsd-soc.sourceforge.net/projects/luakern/ The page mentions some use-cases (like power management and packet filtering) but those can already easily be handed to the userland through the sysfs and tun/tap interfaces for instance. I don't get what problem it's trying to solve.
- pygy_ 13y ago
  LUA_NUMBER can safely be changed to an integer type, Lua is designed for extreme portablity from the ground up. If by stock Lua, you mean lua.c, it is partly intended as a minimal demonstration of how you can embed Lua the library. The authors encourage users to modify the VM to better fit their use case, and changing the number type really is trivial. > Again, maybe I'm just nitpicking but my main point was that lua, scripting language or not, just didn't seem better suited than C at writing device drivers. As I said, I'm mostly unqualified to answer that. It's harder to shoot yourself in the foot when using Lua, which may make things easier at the prototyping stage. Maybe having LPeg[0] could be of some use too. [0] http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html

by pygy_ 13y ago

simias 13y ago

I remember looking at this LUA_NUMBER but I wondered if changing it to an integer type would break something, it's not explicitly mentioned that you can use an integer type there. I'm sure it can be done but it still means that your custom lua will behave a bit differently than the "stock" lua (especially when it comes to things like roundings and overflows). That might be a bit problematic if you prototype your code on one and then attempt to run on the other. As for your improved code I didn't know I could do that, it does look much better indeed. Again, maybe I'm just nitpicking but my main point was that lua, scripting language or not, just didn't seem better suited than C at writing device drivers. That being said, having a good in-kernel REPL would revolutionize kernel hacking, but it seems very hard to do right. Lots of kernel code is very timing-sensitive and you can't afford to wait for user input when you're in a critical path. Just look at the difficulty to implement proper kernel debugging to get a taste of it. The thing is, the NetBSD people know that and more and yet they decided to go with it. I would be very interested to know their objective/motivation. I googled a bit around and found this: http://netbsd-soc.sourceforge.net/projects/luakern/ http://netbsd-soc.sourceforge.net/projects/luakern/ The page mentions some use-cases (like power management and packet filtering) but those can already easily be handed to the userland through the sysfs and tun/tap interfaces for instance. I don't get what problem it's trying to solve.

pygy_ 13y ago
LUA_NUMBER can safely be changed to an integer type, Lua is designed for extreme portablity from the ground up. If by stock Lua, you mean lua.c, it is partly intended as a minimal demonstration of how you can embed Lua the library. The authors encourage users to modify the VM to better fit their use case, and changing the number type really is trivial. > Again, maybe I'm just nitpicking but my main point was that lua, scripting language or not, just didn't seem better suited than C at writing device drivers. As I said, I'm mostly unqualified to answer that. It's harder to shoot yourself in the foot when using Lua, which may make things easier at the prototyping stage. Maybe having LPeg[0] could be of some use too. [0] http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html