From owner-freebsd-hackers Mon Jun 28 14:22:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 866BB1538C for ; Mon, 28 Jun 1999 14:22:54 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA24829; Mon, 28 Jun 1999 14:22:47 -0700 (PDT) (envelope-from dillon) Date: Mon, 28 Jun 1999 14:22:47 -0700 (PDT) From: Matthew Dillon Message-Id: <199906282122.OAA24829@apollo.backplane.com> To: Zhihui Zhang Cc: "Daniel J. O'Connor" , freebsd-hackers@FreeBSD.ORG, Ladavac Marino Subject: Re: RE: Implementation of mmap() in FreeBSD References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :By converge, I mean VOP_GETPAGES() and VOP_PUTPAGES() will call VOP_READ() :and VOP_WRITE() just as read() and write() system call. Yes, but what they are doing is mapping the VMIO cache pages into the buffer, so the VOP_READ/VOP_WRITE essentially operates directly on the VMIO cache pages. This is why NOCOPY is set -- because there is no need to copy the data from the buffer to the VMIO cache because the buffer IS the VMIO cache at that point in time. Confusing, eh? A normal read() or write() syscall always copies the data, because the uio buffer in that case is not VMIO cache but instead some location in the processor's memory. Even if this location were associated with an mmap(), it would almost certainly be to a different file so the copy must occur anyway. A lot of the apparent confusion in the code is due to the fact that the code did not originally implemented a unified buffer cache. It is being slowly cleaned up. :-Zhihui -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message