Messages in this thread | | | Date | Sat, 13 Sep 1997 15:27:40 +1000 | From | Richard Gooch <> | Subject | Re: 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?
Regards,
Richard....
| |