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