Subject: Re: device driver causing fork & exec
To: Todd Whitesel <toddpw@best.com>
From: Stefan Grefen <grefen@hprc.tandem.com>
List: tech-kern
Date: 11/17/1998 17:32:18
In message <199811171548.HAA13387@shell17.ba.best.com>  Todd Whitesel wrote:
> > > 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.

Just use mmap for this. You can even have a global  page with code
and process{group} specific ones that way.

> 
> 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.

You have to install a signal-handler a deliver a signal to the process.
For the adventourous you can try to fake a sigreturn , or just
directly change eip & friends ..

> 
> 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.

Just to deliver the signal is nor problem, to directly execute the code
(after the process is scheduled again of cause) needs the serious hacking
but not in the kernel, just in the driver.

Nice idea 
    Stefan

> 
> Todd Whitesel
> toddpw @ best.com

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---