On Tue, 6 Jun 1995, Charles M. Hannum wrote:

> 
> Actually, maybe I can...
> 
> One idea is to grab a fixed number of DVMA pages at attach time, and
> simply have the driver keep a queue of which ones are available.  That
> way you don't have to fiddle with VM structures; just mark it free,
> and let the PTEs hang around until someone else grabs them.  This does
> have the obvious drawback that the space is always taken, though.
> 
	This queue would be very small?
	If this queue is manipulated at interrupt time, and nested
	DVMA interrupts are not permitted (?), then only one page
	would be active at any given time so the queue could be one
	long? (I _know_ I'm missing something)
	
> ...
> 
> It's occured to me that perhaps the best solution is to have kernel
> threading, and have each driver occupy one thread.  The thread can
> then do whatever is necessary; sleep waiting for memory, fall asleep
> waiting for its interrupt handler to signal an I/O completion so it
> can queue another request, or whatever.  You can also do cleanup for a
> finished transaction in the thread.
> 
> On most architectures (including the i386, soon), switches between
> kernel threads can be very fast, so this shouldn't hurt performance.
> 
	I would guess the concept of kernel threads is going to be
	useful if NetBSD ever moves to MP hardware. (I know, way off,
	but if two solutions offer themselves to a problem niw & they
	are otehrwise similar, might be an idea to think of MP :)

> ...


On Tue, 6 Jun 1995, Charles M. Hannum wrote in reply to my dumb question:

>
>            Presumably the kernel calls xdstragegy()  which sets everything 
>            up & initiates the read request then exits, leaving the process in
>            disk wait.
> 
> No; the strategy routine returns.  In fact, the entire I/O may be
> delayed and done long after the kernel has returned to the process, so
> its context is not necessarily available.
> 
	<clunk>
	I was thinking of reading not writing
	<squeeking noise as head is turned round correct way>
	Thanks :)

			David