Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 5 Jun 1996 11:40:59 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        toor@dyson.iquest.net (John S. Dyson)
Cc:        terry@lambert.org, james@miller.cs.uwm.edu, FreeBSD-current@FreeBSD.org, fcurrent@jraynard.demon.co.uk, grog@lemis.de
Subject:   Re: Vm fixes NG
Message-ID:  <199606051841.LAA29393@phaeton.artisoft.com>
In-Reply-To: <199606050242.VAA02177@dyson.iquest.net> from "John S. Dyson" at Jun 4, 96 09:42:41 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> This discussion of trying to solve the problem of a GUI leaving the
> console in a state that the kernel doesn't know how to change during
> a system crash is interesting.  There is a potential solution (hack)
> that I don't remember being mentioned.  HACK ALERT!!!: Specify a callback
> into user space -- wired specially, with a special system call, that the
> kernel (syscons, pcvt, etc) can call in the case of a crash to fix the problem.
> To make it easiest on the kernel VM people, it would be nice if it would be
> a self-contained module and PIC.  We don't support user space ISRs (yet), but
> this isn't very different from an user space ISR.
> 
> Just a thought.

It's a good thought.  The segment containing such a routine and its
data would need to be locked in core.  If it took a fault, it would
need to fail the process, not the kernel, s a result of the fault.

There is also the problem of associating a credential with the
callback registration.  This gets back into the issue of whether
credentials should be seperate from the process as a container
object.  In the case of an AST implementation (what you are
talking about here is the kernel running user-provided code,
preferrably in the context of a credential and a page map), this
gets especially hairy.  8-).

It probably wants support for multiple code and data segments (COFF
or ELF, basically) to be able to pull it of without locking the whole
thing in core following a registration.  8-(.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606051841.LAA29393>