Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!bloom-beacon!eru!hagbard!sunic!dkuug!freja.diku.dk!rimfaxe.diku.dk!thorinn
From: thorinn@rimfaxe.diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.unix.internals
Subject: Re: How do I find my buffers once I have lost them?
Keywords: kernel virtual sigio
Message-ID: <1990Nov8.134130.7400@diku.dk>
Date: 8 Nov 90 13:41:30 GMT
References: <18747.27394289@windy.dsir.govt.nz>
Sender: news@diku.dk (The Netnews System)
Organization: Department Of Computer Science, University Of Copenhagen
Lines: 28

sramtrc@windy.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.

>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? [Many
>problems described]

This is probably why even those UNIX versions where user programs are
mapped for the kernel (such as any UNIX on a VAX) often don't use this
direct approach. Rather, the driver asks a support routine (physio in
4.3BSD) to take as large a chunk of the user buffer as the driver can
handle and make it ``look like'' a kernel cache buffer.  Usually that
involves locking the pages incore and allocating a buffer header and
some kernel virtual address space to map the chunk. Physio then calls
the device strategy routine, frees up everything and repeats the
process for the next chunk. It is physio that keeps context between
chunks (such as user virtual address and location of the user page
map).

If your UNIX has physio or an equivalent, you're probably better off
using it.

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn@diku.dk