From owner-freebsd-hackers Thu Jan 20 8:34:50 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (vpn.iscape.fi [195.170.146.67]) by hub.freebsd.org (Postfix) with ESMTP id 02B8214FC1 for ; Thu, 20 Jan 2000 08:34:45 -0800 (PST) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id SAA63641; Thu, 20 Jan 2000 18:33:39 +0200 (EET) (envelope-from will) To: adsharma@sharmas.dhs.org Cc: hackers@freebsd.org, zzhang@cs.binghamton.edu Subject: Re: Accessing user data from kernel References: <200001200214.SAA17214@c62443-a.frmt1.sfba.home.com> From: Ville-Pertti Keinonen Date: 20 Jan 2000 18:33:38 +0200 In-Reply-To: adsharma@c62443-a.frmt1.sfba.home.com's message of "20 Jan 2000 04:14:54 +0200" Message-ID: <86puuwd7od.fsf@not.demophon.com> Lines: 28 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG adsharma@c62443-a.frmt1.sfba.home.com (Arun Sharma) writes: > 2. For cases where you've entered the kernel synchronously - through syscalls > for example, you need to check for the validity of data. You could > potentially skip the step and validate the data where it is used, rather > than doing it upfront - but that may mean too many checks. It's just > cleaner to copyin/copyout once at entry/exit, rather than repeating the > code all over the place. That's only part of the story. The copyin/copyout interface provides a portable interface. Some architectures have efficient ways of keeping separate user and kernel page tables, so they require that copyin/copyout be done using unusual methods for access. Additionally, you often want to access data in a section of code where page faulting is not acceptable. Accessing a non-wired memory address implicitly allows you to block. Recovering from fatal faults (translating them into errors) is hard to do properly in C... All methods of accessing user pages while avoiding faults are very slow. So copyin/copyout functions implemented in assembly language are probably the most convenient way of accessing user data in FreeBSD or any other similar kernel. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message