Re: kernel stack challenge

[Horst von Brand]

Sergiy Lozovsky <serge_lozovsky@xxxxxxxxx> said:
> --- Timothy Miller <miller@xxxxxxxxxxxxxx> 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. 

As they say around here "No hay peor ciego que el que no quiere ver"
(roughly, "There is no worse blindness than not wanting to see")...

>                       The only one is that performance
> would suffer because of use of higher level language
> than C or Assembler.

Because the performance and size of kernel code is _critical_, maybe?
Because much of the kernel code has been carefully tuned for maximum
performance perhaps?

> There is a reason people use languages like PERL, Java
> and so on.

And there are solid reasons for _not_ writing operating system kernels in
them too...

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

And then there is the technology of _inventing_ a language tailored to the
task at hand... even better than your list of high-level languages.

> There were times when userland projects were written
> in Assembler. Now people are using other languages,
> too.

In part because a mediocre compiler these days gives better code than an
assembly language coder by hand... and you can compile it for next year's
machine 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
> :-)

It's your time you are wasting... have my blessing.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
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/