[lkml]   [1997]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Console mapping problems? [I hear about these - I wanna know!]
    Jon M. Taylor writes:

    [many words snipped]
    > EvStack is based upon EvPages, fixed-length chunks of data
    > somewhat analogous to network packets. One consequence of this is that
    > there need be no difference between EvStacks and their associated EvPages
    > in kernel and user space! it is all just a bunch of 'packets' of various
    > types, and as a consequence the kernel-user interface transition ceases to
    > be nearly the performance hit it once was. Users can insert and remove
    > their own user-level stacks for their own purposes without affecting
    > anything outside their own priviledge space, let alone having to recompile
    > the kernel! The kernel drivers can stay exactly the same, while what is
    > done with the information they provide is infintely configurable at
    > runtime in userspace! Another useful feature this kernel/user
    > transparency makes posible is very aggressive queueing and pipelineing
    > techniques for message handling on both the kernel and user sides. Fast,
    > fast, fast.

    So your EvStack system provides you with a mechanism to move packets
    around, with the kernel routing and arbitrating access to hardware
    (i.e. some hardware will allow only one access (message in your
    scheme?) at a time, so the kernel will queue the second, third,
    etc. messages until the first is processed)?

    You say that EvStack is very efficient in the way it moves the data
    around. Does it do memory-memory copies (i.e. when moving from kernel
    to user space)? Or does it use MMU tricks to avoid copying?

    It sounds like EvStack (is that short for Event Stack?) is designed to
    be a generic message passing system, is that correct? Have you
    considered the applicability of such a scheme for the networking
    layer? If EvStack was sufficiently generic and fast, especially if it
    solved zero-copy MMU problems, then perhaps you should start talking
    to the network gurus.
    I could see advantages to a fast, generic message passing/queuing
    system for Linux.

    How do you handle user processes sending megabytes of data to a driver
    without the kernel either allocating a similar quantity of RAM or
    locking that RAM? Is there some method to limit the amount of system
    resources the kernel consumes on behalf of a user process?
    If you do MMU tricks, how do you handle a process changing VM mappings
    after queuing a message?



     \ /
      Last update: 2005-03-22 13:40    [W:0.021 / U:23.632 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site