strod@eddie.mit.edu (Eran Strod) (11/09/89)
I posted some questions recently about supporting DVMA at the Device Driver Level on a Sun 3. Thanks to all of those that have answered - you were very helpful! Question 1: Which system call maps user space to DVMA space? Is it just a call to mapin? Answer 1: Physio does this. Mapin maps kernel virtual to physical memory. Question 2: When explaining the MB_CANTWAIT flag of mbsetup, the manual states that it is "highly unlikely" that no "slots in the map or in DVMA space" will be available. How can this be true for devices doing huge transfers? Answer 2: Large requests for DVMA will exhaust available space (1 MB). Question 3: In our scenario, we would like a user program (a C program running on the Sun which controls the AP) to be able to append a DMA operation (a data transfer between a user declared buffer and AP memory) onto the AP's task queue without being forced to sleep until DMA completion. The DMA controller resides on the AP board. Ideally, the user program could continue with other work knowing that the DMA would happen at some later time. When the AP found the DMA operation in its queue of tasks, it would send an interrupt to the Sun in order to request that the user buffer be readied, i.e. that it be mapped to DVMA space, locked in place, etc... Answer 3: When the AP interrupts the host, the device driver's interrupt handler will send a SIGIO interrupt to the process that owns the device. If that process has queued a SIGIO signal handler, then the signal handler can be made to initiate the DMA (the read or write system call will be executed from within process context).