Messages in this thread | | | Date | Mon, 05 Apr 2004 17:12:52 -0400 | From | Timothy Miller <> | Subject | Re: kernel stack challenge |
| |
Sergiy Lozovsky wrote:
> > 1. Give system administrator possibility to change > security policy easy enough without C programminig > inside the kernel (we should not expect system > administartor to be a kernel guru). Language of higher > lavel make code more compact (C - is too low level, > that's why people use PERL for example or LISP). Lisp > was chosen because of very compact VM - around 100K.
And you expect your sysadmins to know LISP? I would hardly think of LISP as any kind of simplification to anything.
I mean, I like the language and all, but it is in no way "simpler" than C and it's definately not appropriate for in-kernel stuff.
> > 2. Protect system from bugs in security policy created > by system administrator (user). LISP interpreter is a > LISP Virtual Machine (as Java VM). So all bugs are > incapsulated and don't affect kernel. Even severe bugs > in this LISP kernel module can cause termination of > user space application only (except of stack overflow > - which I can address). LISP error message will be > printed in the kernel log.
In theory, we could develop the kernel in a language that does all sorts of protection, garbage collection, run-time checking, etc. Kernel developers choose not to because the performance hit would be HORRIBLE.
Now... that doesn't mean you can't do kernel-level stuff in LISP. You just don't do it _in_ the kernel. Given the absolutely MASSIVE overhead you're already incurring by using a LISP interpreter, having to context-switch into user space won't hurt in the least. So, what you do is have a C-based stub in the kernel which passes stuff off to the user-space LISP daemon which calls back into the kernel for accessing devices, etc.
THAT would be a much better way of doing this.
- 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/
| |