lkml.org 
[lkml]   [2004]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kernel stack challenge


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
irrelevant.

> 6. Ability to handle/represent complex data
> structures.

LISP is not superior to other languages in this regard. I
handle/represent complex data structures in C, C++, Java, Javascript,
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.057 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site