> > You could make a page or two of code show up in user space, and deliver
> > a signal to a handler in those pages. This would be a lot more reliable
> > in the low-memory case than a fork/exec would be.
> 
> I didn't know that was possible.  Thanks for suggesting it.  Do you
> know if there are any drivers that already do this, so I can look at
> the code and see how it works?

No clue at all. So I'm cc'ing this back to the list.

Seems to me that the ideal case would be the following:

Device driver contains a small chunk of position independent code that is
a signal handler which you want to be run in user space. At startup you
allocate a page in core and lock it in, then copy the chunk of code to it.

Using pieces of the shared library or shared memory subsystems, make that
page appear in every process -- maybe at a different address, in which case
you'd need an extra field in the process struct to remember the visible
address it has in that process.

When you want the execute part of the code chunk from user space, just
deliver a signal to the process with the right address and let it take
care of the dirty work.

I don't have enough familiarity with the actual NetBSD implementations of
these things to tell you anything remotely resembling example code. But I'm
pretty sure that our implementations should not require excessive tweaking
to be compatible with this scheme.

Todd Whitesel
toddpw @ best.com