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:
> --- Timothy Miller <miller@techsource.com> wrote:
>
>>
>>Horst von Brand wrote:

>>>OK, so you need the policy to be interpreted
>>in-kernel (dunno why a
>>>largeish high-level general purpose language is
>>needed for that, when a
>>>tiny interpreter for a specialized language will
>>do very well, and has been
>>>shown to work fine), and written in a "high level
>>language" so that your
>>>garden variety sysadmin _can_ write her own
>>policy, but it really doesn't
>>>matter because she'll never have to do so...
>>>Completely lost me.
>>
>>I was getting hung up on that one too, but I didn't
>>know how to say it.
>> You did a nice job. :)
>
>
> Can you guys be more specific? I don't see any
> technical objections. The only one is that performance
> would suffer because of use of higher level language
> than C or Assembler.

That IS one of the objections, but it's not the objection HERE.

The objection here is that we see an inconsistency:

A) You support the idea of using LISP because it's a high-level language
that sysadmins can use to develop policies.

B) But then you say that sysadmins won't be developing policies.

Therefore, you invalidate your reason for wanting to use LISP.

>
> There is a reason people use languages like PERL, Java
> and so on. I would prefer to spend less time writing
> actual code - this is what these high level languages
> for. If performance would be most important - people
> would do everything in Assembler, but they don't. I'd
> better write a small Assembler subroutine which will
> handle stack problems for me and benefit from using
> the high level language after that.

As a matter of fact, the only reason people object to using LISP is
because you want to do it IN THE KERNEL.

If you want the interpreter to live in the kernel, then you have to use
something MUCH SIMPLER and something which doesn't eat stack like LISP does.

On the other hand, if you were to put hooks into the kernel so that
people could use ANY LANGUAGE THEY WANTED, IN USER SPACE, then people
would be very happy with you. This way, you can waste all the memory
you want on the interpreter, but it's okay because it's:

(1) extremely optional
(2) extremely replacable (interpretor can be any language)
(3) swappable
(4) can't clobber the kernel
(5) can use as much stack space as it wants
(6) minimally impacts what IS in the kernel, etc.

You down-play the performance impact of using LISP above, but you
contradict that by saying you want to put the interpreter in the kernel
for performance reasons. You can't have it both ways. Either you're
concerned about performance (and you use something efficient and
compact), or you're not concenred about performance (and you use
whatever high-level language you want IN USERSPACE).


>
> There were times when userland projects were written
> in Assembler. Now people are using other languages,
> too. May be it's time to try something new in the
> kernel, too :-) Or we will not consider that because
> nobody did that before? Someone should be the first
> :-)

The kernel is not the appropriate place for this. An OS kernel exists
to provide a minimal set of services necessary for applications to make
efficient use of resources. (Microkernels take this to the extreme with
their layering.) Only when something CANNOT be accomplished in
userspace (or performance in userspace is terrible) should something be
put into the kernel.

As I've said before, the overhead of actually interpreting a high-level
language is probably great enough that the context-switch overhead you
don't want would diminish.

-
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.065 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site