Subject: Re: incomplete 64bit off_t implementation
To: Matthias Drochner <drochner@zelux6.zel.kfa-juelich.de>
From: Eduardo E. Horvath <eeh@one-o.com>
List: tech-kern
Date: 05/29/1997 08:47:42
On Wed, 28 May 1997, Matthias Drochner wrote:

> It's obviously not possible to mmap() an object beyond the 4G limit.
> The first thing sys_mmap() does is to truncate the offset to
> a vm_offset_t. (all kinds of offsets, into local vm space or into
> external objects, are of that type)
> It seems not too hard to solve this by replacing the vm_offset_t
> by off_t at the appropriate places.
> Is it worth trying or are there deeper reasons that there is
> no separation between vm offsets and external ones?
> 
> (I want to use it to mmap() portions of the (64bit) SCI
> address space on a i386.)

I think there is an inherent problem in the vm (actually pmap) code.
vm_offset_t should be used for virtual addresses and offsets, but in the 
function definitions it is used for everything.  There should be a
a pa_offset_t which is opaque to MI code.  This would simplify running on
machines where sizeof(vm_offset_t) < sizeof(pa_offset_t).  I would think
this would lend itself to several architectures we currently have ports on
such as SPARC with its ASIs and x86 with its segment descriptors.

I expect to send-pr this one of these days when I get send-pr working.

=========================================================================
Eduardo Horvath				eeh@btr.com
"Cliffs are for climbing.  That's why God invented grappling hooks."
					- Benton Frasier