Re: Adding Lua to the kernel and moving Lua source codes
Jean-Yves Migeon wrote: Le 07/10/2013 12:05, Alan Barrett a écrit : I still haven't seen a use case for in-kernel Lua. I mean, an example (preferably a working example) of something useful that could not easily be done without in-kernel Lua. I'd prefer not to see it added to the base system without a use case. I second the use case. Not something as polished or finished as possible, but at least shows that it is useful (I am well aware of the cause/effect circle ie. you cannot prove it without having Lua first available, but breaking that vicious circle with a few examples can help). In the early days of bpfjit when I didn't yet know of sljit, I was considering ripping off lua code for generating machine instructions from LuaJIT2 code. I still believe that rewriting bpfjit in Lua would improve readability. I even started a rewrite mostly as a good use-case for Lua bindings for sljit but it's low priority project for me. Alex
processor abstraction
A lot of systems are coming with compute/peripheral processors with limited ram, etc. I was wondering what the abstraction should be? Obviously, mmap()'ing their memory would be nice. But what about stopping/starting? Messaging? Ideas are welcome.
Re: processor abstraction
Hello, on Monday 07 October 2013 20:48:04 Masao Uebayashi wrote: On Tue, Oct 8, 2013 at 7:24 AM, Matt Thomas m...@3am-software.com wrote: A lot of systems are coming with compute/peripheral processors with limited ram, etc. For example? I guess he means things like the DSPs found in OMAP SoCs, SGI's VICE, possibly Cell's SPEs, maybe even things like the 8051 integrated into things like the Silicon Motion SM502. May or may not have their own MMUs or analogues ( VICE has some private RAM and host-controlled DMA machinery for example ), usually there's a mechanism to send interrupts between host and peripheral processors. have fun Michael