lkml.org 
[lkml]   [2007]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 06/11] syslets: core, documentation
    On Wed, 14 Feb 2007, Russell King wrote:

    > Let me spell it out, since you appear to have completely missed my point.
    >
    > At the moment, SKIP_TO_NEXT_ON_STOP is specified to jump a "jump a full
    > syslet_uatom number of bytes".
    >
    > If we end up with a system call being added which requires more than
    > the currently allowed number of arguments (and it _has_ happened before)
    > then either those syscalls are not accessible to syslets, or you need
    > to increase the arg_ptr array.

    I was thinking about this yesterday, since I honestly thought that this
    whole chaining, and conditions, and parameter lists, and argoument passed
    by pointers, etc... was at the end a little clumsy IMO.
    Wouldn't a syslet look better like:

    long syslet(void *ctx) {
    struct sctx *c = ctx;

    if (open(c->file, ...) == -1)
    return -1;
    read();
    send();
    blah();
    ...
    return 0;
    }

    That'd be, instead of passing a chain of atoms, with the kernel
    interpreting conditions, and parameter lists, etc..., we let gcc
    do this stuff for us, and we pass the "clet" :) pointer to sys_async_exec,
    that exec the above under the same schedule-trapped environment, but in
    userspace. We setup a special userspace ad-hoc frame (ala signal), and we
    trap underneath task schedule attempt in the same way we do now.
    We setup the frame and when we return from sys_async_exec, we basically
    enter the "clet", that will return to a ret_from_async, that will return
    to userspace. Or, maybe we can support both. A simple single-syscall exec
    in the way we do now, and a clet way for the ones that requires chains and
    conditions. Hmmm?



    - Davide


    -
    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: 2007-02-14 18:55    [W:4.379 / U:0.236 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site