Date: Wed, 13 Dec 2000 19:11:43 -0800 From: Mike Smith <msmith@freebsd.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: arch@FreeBSD.ORG Subject: Re: Proposed bus address typedef. Message-ID: <200012140311.eBE3Biu02171@mass.osd.bsdi.com> In-Reply-To: Your message of "Wed, 13 Dec 2000 00:28:24 PST." <200012130828.eBD8SOT81109@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012140311.eBE3Biu02171>