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


    Patrick J. LoPresti wrote:

    >>It's a limited number of people who would actually write these
    >>policies. If those people follow certain coding rules, then we CAN
    >>have such bounds, by convention. Yes, those bounds could be violated,
    >>but if the programmer (not sysadmin -- they would never write these
    >>things in LISP) breaks something, it's just a bug.
    >
    >
    > Fair enough. But then I wonder how many of Lisp's advantages you
    > would lose. I am having trouble imagining "statically bounded Lisp"
    > without being so stylized as to hardly be Lisp at all.
    >

    Given that the original author admits that the sysadmins using this
    would never actually write any LISP code, I too fail to see why LISP
    would be of any help here.

    If you want to be compact and efficient, some really simple
    pseudo-language would do the job well enough. Optimize for speed of
    execution and compactness of both interpreter and policy code, not for
    easy of writing in the language.

    I mean, by choosing LISP, "ease of writing in the language" was thrown
    out the window to begin with! :)

    I think this points us in the direction of something like Forth. Take
    OpenBoot for example. I wrote Forth-like interpreters in Pascal when I
    was in highschool.

    But if you DO want sysadmins to be able to write this, then something
    resembling shell script would be better. It wouldn't be quite like
    shell scripting, but it would LOOK like it, and it would have to be
    compiled (by the program that you run to load the policy) into something
    compact and easy to interpret before being fed to the kernel.

    Another possibility is to develop a set of tools that compile policies
    written in C into modules that are loaded/unloaded into the kernel
    dynamically. :) The compile process would be transparent to the user,
    because the "insert this policy" tool would run it through GCC (unless
    the cached .ko was already up to date, etc.).


    -
    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.020 / U:124.352 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site