A lot of the discussion here has been around Lua, but not around what they do with it. I think that putting yet another language and runtime in the OS kernel i

A lot of the discussion here has been around Lua, but not around what they do with it. I think that putting yet another language and runtime in the OS kernel is a bad idea. It makes the amount of code to validate much bigger. I much prefer the Mill Computing approach to security, where "everybody works the same" including the kernel (see http://millcomputing.com/docs/security/ http://millcomputing.com/docs/security/ if you have not seen it already). That's also the idea behind many microkernels. Although the Mill CPU embeds basic mechanisms in the hardware to make it easier, I believe this could be achieved on modern x86 or ARM as well with reasonable performance. You don't need privileged instructions to deal with packet routing or CPU throttling, you only need controlled memory access to specific regions of memory (e.g. device registers, buffers, etc). I see no reason why the scripts could not do their work from user-space, with kernel-controlled access to the regions of memory they need to operate. And the overhead in doing that is practically zero (basically, it's the cost of the TLB translations, which is paid for every single memory access anyway). Obviously, you also need inter-process and inter-CPU synchro, interrupt handling, etc. But all these are already presented in a virtualised form to user-space. Also, if you want the flexibility of a scripting language, you are willing to forego quite a bit of performance in the process. Is the cost of a user-kernel transition really that relevant in this scenario? And if it is, there are mechanisms to mitigate that cost, e.g. pooling requests, deferring, sending to another CPU, etc. I'm a bit appalled by the way they measure the overhead (Section 5 of the article). They say that their CPU rethrottling code runs in "only" 8 microseconds. Well, if compared to the rescheduling interval, it may seem small, 8 microseconds in kernel code is actually a lot. It means 1/125 of a regular millisecond tick. All this just to change the frequency of the CPU? In short, I agree with the objectives (making the OS more extensible and more flexible), but the way they did it seems dangerous and under-optimal.