Date: Fri, 24 Sep 2004 14:11:19 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= <des@des.no> Cc: freebsd-hackers@freebsd.org Subject: Re: execute a user process in the kernel Message-ID: <Pine.NEB.3.96L.1040924140940.82478L-100000@fledge.watson.org> In-Reply-To: <xzpekkrwsca.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 24 Sep 2004, Dag-Erling Sm=F8rgrav wrote:
> execve(2) assumes you already have a process. You get a process by
> forking another process. The only process we ever create from scratch
> is init(8), and that takes a s**tload of work (see kern/init_main.c).=20
> This is why we have stuff like nfsiod(8) which does nothing but provide
> the kernel with a process context it can use for other stuff.=20
>=20
> You could, of course, write a kernel API for creating processes from
> scratch. They'd still need a parent, but you can use init(8) (pid 1)=20
> for that.=20
Well, we have kproc/kthread APIs, but none of that is semantically
compatible with the notion of execve(), which is a very user-centric
concept ("replace the address space with a mapping of binary <x>"). You
could fudge together a related notion, though, involving loadable kernel
modules that have a main() routine run from a thread. That said, the
notion of simply running user code in kernel (as has been pointed out) is
fraught with peril, primarily because the kernel is basically one big
program with many special requirements, and user applications are written
with the assumption that they are the only program, not running in the
context of another program.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040924140940.82478L-100000>