From owner-svn-src-head@FreeBSD.ORG Fri Mar 2 18:19:37 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BAC271065678; Fri, 2 Mar 2012 18:19:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 86CCF8FC15; Fri, 2 Mar 2012 18:19:37 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 3B91B46B0A; Fri, 2 Mar 2012 13:19:37 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8159FB948; Fri, 2 Mar 2012 13:19:36 -0500 (EST) From: John Baldwin To: Bruce Evans Date: Fri, 2 Mar 2012 09:52:33 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201202281815.q1SIFSbB082030@svn.freebsd.org> <201203012346.00228.tijl@freebsd.org> <20120302151400.Y1224@besplex.bde.org> In-Reply-To: <20120302151400.Y1224@besplex.bde.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203020952.33378.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 02 Mar 2012 13:19:36 -0500 (EST) Cc: svn-src-head@freebsd.org, Tijl Coosemans , src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r232261 - in head/sys: amd64/include i386/include pc98/include x86/include X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 18:19:37 -0000 On Friday, March 02, 2012 12:10:38 am Bruce Evans wrote: > It's too late to change vm types. The distinction between addresses > and sizes became useful first with file offsets (vm_ooffset_t. BTW, > what is an o offset?) and then for physical offsets. The 'o' stands for 'object', so 'vm_ooffset_t' is a VM object offset (at least that's my interpretation). -- John Baldwin