From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 7 11:41:22 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F15A16A4CF for ; Sun, 7 Dec 2003 11:41:22 -0800 (PST) Received: from pythagoras.math.uwaterloo.ca (pythagoras.math.uwaterloo.ca [129.97.140.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB3D043FCB for ; Sun, 7 Dec 2003 11:41:18 -0800 (PST) (envelope-from anand@pythagoras.math.uwaterloo.ca) Received: (from anand@localhost) by pythagoras.math.uwaterloo.ca (8.11.7/8.11.7) id hB7JfIK10146; Sun, 7 Dec 2003 14:41:18 -0500 (EST) Date: Sun, 7 Dec 2003 14:41:17 -0500 From: Anand Subramanian To: freebsd-hackers@freebsd.org Message-ID: <20031207144117.A6912@pythagoras.math> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i cc: anand@cs.uwaterloo.ca Subject: Sharing data between user space and kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2003 19:41:22 -0000 A look at the copyin() code in the kernel reveals that all the kernel needs to do to access the data(address space) of a user process is 1. Get the current thread, which I saw is done using the PCPU_GET macro. So I suppose this is always preserved upon a system call. 2. Set the segment register for the user process correctly. And magically, all the user process's data can now be accessed by the kernel directly. Is that correct? In the event of which, it would become really easy for a user process to allocate a chunk of memory and all a kernel module needs to do to "implement shared memory" is do the steps 1 & 2 and access the data. Of course there is the question that the user process is "swapped" out after the system call and some other thread starts running in between in which case curthread should point to some other thread and not the one that issued the system call. But then, isn't this what happens upon every system call normally, when the kernel does the steps 1 & 2 to obtain the data arguments which are passed to the system call. So this is hardly a problem. So, can shared memory be implemented this way instead of the more traditional "pseudo-device" way? Appreciate any comments on this(please do a CC to my email address, in case you choose to respond). Anand