How do I find my buffers once I have lost them?

[Boyd Roberts]

In article <18747.27394289 at windy.dsir.govt.nz> sramtrc at albert.dsir.govt.nz writes:
>Suppose I have a UNIX version which maps a user program into the kernel
>virtual space. Then accessing a user buffer by the kernel is easy since
>the buffer has an address in the kernel virtual space. Suppose the kernel
>wants to send the user buffer to a device in several transfers. This is
>easy because the kernel tells the device the address of the buffer, starts
>the transfer, and waits for an interrupt from the device.
>
>When the kernel gets the interrupt how can it find the user buffer again
>(assuming it has been locked into memory) to do the next transfer?

Usually the user data is copied into a kernel mode data structure* with
copyin() [iomove() in the read()/write() case].  The copy is done
precisely to avoid the problem of being able to reference the data when
the process's context is not available for reference.  This approach is
usually ok, but sometimes you want to DMA straight to the process's
address space.

To do that I've often cheated by getting physio() to do the hard work.
My character based driver has a `dummy' strategy routine et al and
it's called from physio().  The driver calls physio() and physio() locks
down the process and does all the foul machine dependent mapping and calls
the strategy routine until the I/O is complete.  The process is unlocked,
the DMA done.

Of course, your kernel may not do exactly what I described.  There may be
other hooks to validate pages, lock them down and provide a kernel mapping
to them.  Then again, there may be none that suit your application.



Boyd Roberts			boyd at necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''

* How you get that data structure is your problem and is specific to
  the driver and kernel.  Just make sure it's in context when you want
  to reference it.  The kernel stack is just a no-no.