Re: kernel stack challenge
From: Timothy Miller
Date: Tue Apr 06 2004 - 17:25:23 EST
Sergiy Lozovsky wrote:
So, you still didn't say a word why it was a bad
choice. Can you share your thought on that?
I've seen (and produced) lots of words to that effect.
I didn't just pick up LISP - I EXPLAINED my reasons.
if you missed my explanation here is a short summary.
1. I needed solution to implement some procedural
functionality within the kernel. This functionality
should be expressed with some high level language
(shorter development time and more compact source
code). This functionality should be
loadable/unloadable to the kernel.
This isn't a problem.
2. Size of the interpreter should be minimal.
You say your LISP interpreter is about 100K. This is hardly minimal.
There are things which are much smaller which will do the job AND won't
have the stack-exploding side-effects.
3. Kind of real time - no ordinary garbage collector.
And automatic memory management at the same time.
How about one which doesn't NEED garbage collection? For instance, if
you were to make it object-based, rather than object-oriented, then
you'd pre-allocate all structures at compile time. Ada is(was?) like this.
4. Easiest syntax possible - so interpreter would be
compact. Simpler - the better :-) I don't like
complicated things :-)
LISP completely violates this requirement. There are languages which
have MUCH simpler syntax than LISP.
And I'm talking simpler for the PROGRAMMER. It can be as complex as you
like for the compiler, because THE COMPILER WOULD BE IN USERSPACE.
5. Well known. So there would be people around who
already know this language and expectations are clear.
And there are books around about this language.
LISP completely violates this requirement. While I appreciate the power
of LISP for abstraction, list processing, and how it lends itself
towards many AI-related tasks, it's not a commonly-used language.
Besides, you have already invalidated this point by stating that the
people actually USING this policy engine would never look at the code,
because they would select amongst a set of canned policies using a web
browser. In this case, the form of the policy code is completely
6. Ability to handle/represent complex data
LISP is not superior to other languages in this regard. I
PHP, SQL, BASIC, Pascal, Tcl... I guess FORTRAN is the only one I don't
do complex structures in.
7. Errors/bugs in loadable functions should not cause
trouble for other tasks and kernel itself. (To the
extent possible for sure).
The only way to be sure of this is to do the processing in userspace.
Putting that aside, any carefully-written interpreter would be able to
provide this security. Furthermore, something simpler than a LISP
interpreter would be easier to VERIFY that it was secure.
8. It should be universal (general purpose) language
which gives ability to make any manipulations with
numbers, strings, bits and data structures. So I would
be sure that functionality I want to express is not
limited by the language.
Again, LISP is not superior to other languages in this regard.
That's why particular LISP interpreter was chosen.
It's wrong to say that just language was chosen. I
would never start work of fitting Common Lisp into the
kernel. Particular general purpose language
interpreter was chosen.
You have to understand that you're speaking to a list full of zealots
that understand zealotry VERY WELL. Even Linux scratches his head (or
so I assume) every time some Linux zealot comes along wanting to run
Linux on some two-bit (pun intended) processor that was never designed
to run an OS.
Thus, when someone comes along suggesting that they put a beast like a
LISP interpreter into the Kernel, something that violates Linux
philosophy on SOOO many levels, the "he must be a LISP zealot" red
lights start flashing, because only a LISP/whatever zealot would choose
to do something so ostensibly impractical. That is to say, someone who
was NOT a LISP/whatever zealot would have chosen something more
appropriate, while we have observed so many times
Linux/LISP/MacOS/BeOS/Perl/Ruby/Python/whatever zealots who want to push
their square peg into every round hole they can find. (so to speak)
I personally like to write Nuclear Bomb simulators in BASH to run on
5mhz processors with 1K of RAM. *snort*
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/