Re: Console mapping problems? [I hear about these - I wanna know!]

Richard Gooch (rgooch@atnf.CSIRO.AU)
Sat, 13 Sep 1997 15:27:40 +1000


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....