Memory mapping/allocation problem.

[Marinus van Splunter]

We are about to write some software for a VME based processor, and the Sun
manuals were too mystifying for us to be of any direct use.  As we think
that this problem should have been solved before, we thought we'd ask the
Net to see if anyone can give us some clues, source code fragments, or
anything that might be of help.

Here are the facts:
- The processor is stand-alone, and has no local memory on board.  This
  means that it must have access to the main memory of the Sun processor.
- The processor processes loads of data (yeah, which one doesn't? :-), and
  to avoid unnecessary copying we'd like to be able to supply it a
  (physical/logical?) address that points to a bunch of data generated by
  some process. 

Here is how we envision the flow of things:
- A process allocates some memory, and fills it with more or less useful data.
- It makes sure the data is not swapped out until further notice.
- It obtains the physical address of where the data is located.
- It transfers the pointer to the VME processor, and starts it up.
- It sleeps until the VME processor is done.
- It picks up the answer (42 ;-) and releases the memory.

An alternative would be to supply the logical address to the processor,
and make the system translate its addresses into physical addresses.  What
happens during sleep time then? When a process is swapped out, another
process' mapping will be filled in the MMU....

And now... the questions!
- What does the memory map of a sun system look like from the VME bus?
- Precisely how can a VME processor gain access to the main memory in a
  Sun?  (What address modifier should be used, can addresses be translated
  from logical into physical, etc?)
- Does mmap() keep the data from being swapped out while you're asleep?
- Do we absolutely need to write a device driver to pull this off?
- What are the differences between Sun3 and Sun4 systems in this respect?

Again, any pointers (logical or physical :-), code fragments or
suggestions are appreciated. We will post a summary of the reactions on
the net.

Thanks in advance,
			Marinus van Splunter
			Evert-Jan Pol

E-mail: marinus at vangogh.prl.philips.nl
	evert at vangogh.prl.philips.nl