From owner-cvs-src@FreeBSD.ORG Wed Apr 26 16:15:11 2006
Return-Path: <owner-cvs-src@FreeBSD.ORG>
X-Original-To: cvs-src@FreeBSD.org
Delivered-To: cvs-src@FreeBSD.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 778C816A408;
Wed, 26 Apr 2006 16:15:11 +0000 (UTC) (envelope-from imp@bsdimp.com)
Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85])
by mx1.FreeBSD.org (Postfix) with ESMTP id C981243D48;
Wed, 26 Apr 2006 16:15:09 +0000 (GMT) (envelope-from imp@bsdimp.com)
Received: from localhost (localhost.village.org [127.0.0.1] (may be forged))
by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k3QGCVD8038563;
Wed, 26 Apr 2006 10:12:32 -0600 (MDT) (envelope-from imp@bsdimp.com)
Date: Wed, 26 Apr 2006 10:12:45 -0600 (MDT)
Message-Id: <20060426.101245.90994186.imp@bsdimp.com>
To: scottl@samsco.org
From: "M. Warner Losh" <imp@bsdimp.com>
In-Reply-To: <444F0923.8050508@samsco.org>
References: <20060426103623.M1847@epsplex.bde.org>
<20060425223519.F65802@ns1.feral.com> <444F0923.8050508@samsco.org>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: src-committers@FreeBSD.org, bde@zeta.org.au, jhb@FreeBSD.org,
cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, mj@feral.com
Subject: Re: cvs commit: src/sys/dev/bce if_bcereg.h
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Apr 2006 16:15:11 -0000
In message: <444F0923.8050508@samsco.org>
Scott Long <scottl@samsco.org> writes:
: Matthew Jacob wrote:
: >
: >> Supporting sizes >= 4G sounds unreasonable. How can a single device
: >> need or even address so much space, even on 64-bit arches? For vm,
: >> virtual memory is sort of a device, but even it is limited to 4G on
: >> 32-bit arches, and PAE on i386 isn't pessimized by using a larger than
: >> necessary vm_size_t.
: >
: >
: > I have need to support and help people sell machines that use 32GB of
: > directly addressable memory. In fact, the EM64T cheat will shortly
: > become an embarrasment to Intel when people find out that EM64T with PAE
: > is *not* the same as Opteron (36 vs. 40).
: >
: > I'm afraid I don't understand the 'unreasonable' argument here. Linux is
: > eating your lunch today. Do you want it to eat your dessert as well?
: >
: > -matt
: >
:
: bus_size_t is used for things like measuring transfer segment size.
: There is little chance that Linux, Windows, FreeBSD, or any other OS
: is ever going to try to DMA more than 2^32 bytes of data in a single
: bus transaction. Maybe you could contrive a silly infiniband device
: to do it. Anyways, it has no bearing on whether the CPU, memory
: controller, or PCI buses can do 64 bit addressing.
bus_size_t is for differences between two bus_addr_t quantities, since
it specifies the size of resources on a bus. It is also used for
transfer sizes and the like. That's why I think it should be a 64-bit
quantity: 64-bit - 64-bit = 64-bit.
Warner