From owner-freebsd-arch Wed Dec 13 19: 1:55 2000 From owner-freebsd-arch@FreeBSD.ORG Wed Dec 13 19:01:53 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (dhcp242.osd.bsdi.com [204.216.28.242]) by hub.freebsd.org (Postfix) with ESMTP id A216A37B404 for ; Wed, 13 Dec 2000 19:01:51 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id eBE3Biu02171; Wed, 13 Dec 2000 19:11:45 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200012140311.eBE3Biu02171@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Matt Dillon Cc: arch@FreeBSD.ORG Subject: Re: Proposed bus address typedef. In-reply-to: Your message of "Wed, 13 Dec 2000 00:28:24 PST." <200012130828.eBD8SOT81109@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Dec 2000 19:11:43 -0800 From: Mike Smith Sender: msmith@mass.osd.bsdi.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just in summary; I think I'm hesitant to do anything about this yet. Matt Jacob raises some good points about some of the more complex compound address constructs that I haven't thought through, so I will let the matter mostly lie. I'd like to address something here though: > Pointers on IA32 are still > 32 bits... just 32 bits per address space. Virtual addresses remain 32 bits. Physical addresses (which includes the address of both regions to be mapped into virtual space, as well as the targets of DMA operations) may be larger. > So there is no particular > need for them to be visible outside the device driver core. This isn't correct; the resource manager needs to be able to track these resources, and the busspace and busdma code needs to be able to handle these physical addresses. > Most of > the rest of the kernel that accesses a physical address could just as > well use a page index rather then an actual address. A page index still > fits in an int (i.e. vm_page_t->phys_addr could easily become a page > index, or could become a machine-dependant MMU compatible value if not > a page index). Most of the rest of the kernel either uses virtual > addresses, which are still 32 bits, or block numbers. If the change can > be made without impacting the size of heavily used system structures > I'm all for it. I think your bias is very heavily towards the VM system, in whose domain you are undoubtedly correct. My intention was simply to find a way for the I/O subsystem to deal with a physical address space significantly larger than the virtual address space. In hindsight, this may be too narrow a scope for such a change, however a more complex resolution would require a lot of effort to get "right" and may not be helpful given the small domain of usefulness for this. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message