lkml.org 
[lkml]   [1996]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: 2.2.0 wishlist
    Date
    Wild idea test....

    One possible utterly non-standard concept I've been toying with:

    Asynchronous/Repeatable "slates" of system calls.

    This would allow the following:

    1) Setting some kernel/lib feature to tape-record all syscalls
    (or syscalls of various types) with all the live addresses and
    arguments kept intact (careful regarding stack variables!).
    (Probably even executing them as called.. but recording them too).

    The sequence of calls made is then considered to be on a "slate."
    with some system-global or process-indexed ID number (maybe used
    via a /dev/file mapping?).

    2) Then, any time desired the whole slate of calls can be invoked and
    any non-zero returns can be delivered via signal or placed in a user
    buffer and a flag set. They could be operated on in order or in
    parallel. The single "run-slate()" call returns upon the slate's
    complete execution in kernelspace.

    This would allow very high speed operations of devices that require a
    sequence of system calls and/or ioctls that have to enter kernel
    space. It would allow complex manipulations to be much more reliable.
    Since user memory is still active, one could change user memory and
    then re-run the slate again and again with the varied parameters.

    If one wanted to get *really* fancy, various guards could be set for each
    system call, preventing some from running but allowing others.

    It would also provide a useful means of encapsulating *any* asynchronous
    interface in the kernel. If a system call could require a
    "start/done_yet" pair of calls (the second is for polling completion)
    and you have 18 of them.... Great! Just make a "slate" that is
    composed of all the various "done_yet()" calls, as well as a slate of all the
    "start" calls. Launch the starts in "parallel" and receive a
    "not-done-yet" status from every one that isn't done. Keep polling the
    slate until all of those needed return "success". (This could allow
    partial recovery when a few have succeeded but the rest are still pending).

    (This could also allow more incredibly lightweight polling calls to
    be implemented because they'd suddenly become practical.. in large numbers).

    The whole deal could remain compatible with other platforms too. "Record"
    the same slate of done_yet calls (i.e. without real recording support) as a
    poll and then use that as the "slow" version of the Linux
    asynchronous-replay feature.

    Note here:
    - no new kernel threads are needed, because its merely a lonnnng "composed"
    system call
    - no user/group permissions are a problem
    - nothing more than the same load problems that already exist could happen
    (unless the slate was too big for a single ctxt-switch)

    Its just a high performance and async-polling hack, but for Gamez or for really
    zippy stuff, I cannot see missing out on composing such nifty kernelspace
    benefits. The amount of time saved for some device controller, sound, for
    some high speed graphics, a complex configuration sequence, or for
    quick and repetative mass-slorping of information,.. the benefit could be
    substantial.

    - Christopher H.


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