From owner-freebsd-current Wed Dec 18 08:21:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA13464 for current-outgoing; Wed, 18 Dec 1996 08:21:06 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id IAA13459 for ; Wed, 18 Dec 1996 08:21:04 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA10100; Wed, 18 Dec 1996 09:17:57 -0700 From: Terry Lambert Message-Id: <199612181617.JAA10100@phaeton.artisoft.com> Subject: Re: Plan for integrating Secure RPC -- comments wanted To: dg@root.com Date: Wed, 18 Dec 1996 09:17:57 -0700 (MST) Cc: terry@lambert.org, jkh@time.cdrom.com, wollman@lcs.mit.edu, current@freebsd.org In-Reply-To: <199612180132.RAA09636@root.com> from "David Greenman" at Dec 17, 96 05:32:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> > Better to just fix the LKM mechanism to not need it... There are ways > >> > to do this, but they are all sort of unappealing. > >> > >> Yeah, I've heard the "move ld into the kernel" arguments too. > >> > >> That's why I was suggesting this as an interim work-around solution. > > > >mmap() the loader into the address space of the moload process, and > >call it from kernel mode. > > That won't work for a variety of reasons. For one thing, the kernel is > not going to like demand paging (COW, zero-fill, regular page faults) in the > context of the kernel. For another, the kernel stack is of finite size and > can't deal with typical programs. Using the user's stack is "a major problem" > in it's own right. Heh. On the other hand, it could be forced to work using the user's stack. We were discussing interim workarounds anyway, not anything long term. If you issues "touches" on the code from the user stack after an initial vn_read, you could do it... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.