5 ms·
As someone who once threw together a Lua kernel module for FreeBSD 4 just for fun, I approve of the idea -- although I don't know how useful it is. Being able
by cpressey 14y ago
As someone who once threw together a Lua kernel module for FreeBSD 4 just for fun, I approve of the idea -- although I don't know how useful it is.
Being able to rapidly prototype kernelspace things is probably the main advantage. I'd think twice about actually running garbage-collected code in the kernel in production. And the slide that touts that it's easy for users to modify -- yes, well -- you could easily argue that it shouldn't be easy for users to modify what's in the kernel :)
- AlexanderDhoore 14y agoIndeed, prototyping functionality is the main point here. The whole system isn't even part of the default install and can be turned on/off. Easier is always good. It's still far from easy though.
- Nelson69 14y agoI've seen this on an embedded product that has been sold for years. The license is liberal, it's remarkably easy to work with Lua, is can basically call any of your C functions. Great for debugging stuff, prototyping, certain kinds of monkey patches. Great for doing unit test like experiments too; you can have some Lua put the system in to a particular state and then do your experiment.
- AlexanderDhoore 14y agoHow would you compare it with python for things like unit testing c code? Here lua is chosen because of it's small footprint, but for testing that doesn't really matter.
- reddit_clone 14y agoLua is multi-threading friendly. It is allowed and easy to run multiple VMs in different threads in the same process.
- xradionut 14y agoI believe MicroMint, (aka Steve Ciarcia's hardware company), offers Lua on a few ARM boards.
- KMag 14y agoYea, I agree that it's neat, but probably of limited practical value. If you need something like this, it's probably best to either host a kernel in userspace (like UML), or else have a lightweight kernel interface that allows you to do your heavy lifting in userspace. I've never done any Plan9 driver development, but my understanding is that Plan9 has userspace equivalents of most of the internal driver API calls, so that a driver module can almost seamlessly be developed as a userspace driver and then (if it turns out to be performance critical) run as an in-kernel module in production. Once you've got good userspace APIs for the kernel APIs you need to use, then all kinds of rapid prototyping possibilities open up.