Messages in this thread | | | Date | Thu, 1 Mar 2007 02:33:01 +0100 | From | Andrea Arcangeli <> | Subject | Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3 |
| |
On Thu, Mar 01, 2007 at 12:12:28AM +0100, Ingo Molnar wrote: > more capable by providing more special system calls like sys_upcall() to > execute a user-space function. (that way a syslet could still execute > user-space code without having to exit out of kernel mode too > frequently) Or perhaps a sys_x86_bytecode() call, that would execute a > pre-verified, kernel-stored sequence of simplified x86 bytecode, using > the kernel stack.
Which means the userspace code would then run with kernel privilege level somehow (after security verifier, whatever). You remember I think it's a plain crazy idea...
I don't want to argue about syslets, threadlets, whatever async or syscall-merging mechanism here, I'm just focusing on the idea of yours of running userland code in kernel space somehow (I hoped you given up on it by now). Fixing the greatest syslets limitation is going to open a can of worms as far as security is concerned.
The fact that userland code must not run with kernel privilege level, is the reason why syslets aren't very useful (but again: focusing on the syslets vs async-syscalls isn't my interest).
Frankly I think this idea of running userland code with kernel privileges fits in the same category of porting linux to segmentation to avoid the cost of pagetables to gain some bit of performance despite losing in many other areas. Nobody in real life will want to make that trade, for such an incredibly small performance improvement.
For things that can be frequently combined, it's much simpler and cheaper to created a "merged" syscall (i.e. sys_spawn = sys_fork+sys_exec) than to invent a way to upload userland generated bytecodes to kernel space to do that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |