eeh@turbolinux.com said:
> It would be really nice to solve this once and for all, especially the
> return value from (*dev->mmap)() so we don't need to come up with some
> silly wrapper to somwhow try to sqeeze 64-bits of addressing
> information into a 32-bit `int'.

I always found it strange that the device driver's mmap()
methods have to employ an MD "btop" function to return
a "page frame number" which can't be interpreted by MI code
in any useful way. The only thing the device pager does with
it is to pass it to pmap_phys_address() which is MD again.
It would be only logical to make this intermediate type
completely opaque for the MI VM code.

> vaddr_t is supposed to hold a pointer in a machine's virtual
> address space.  voff_t is supposed to hold an offset in the machine's
> virtual address space, the equivalent of the new C9x ptrdiff_t.

Hmm - then I've misunderstood the intent behind voff_t.
I was assuming that it holds an offset into the space of a VM _object_,
which is abstract and quite independant of MD issues - it is more or less
the prolongation of the filesystem's "off_t" into VM world.
On the i386 eg there is no point in defining a 64-bit offset
into the machine's VM space, but it is still useful to mmap
some part of a large file beyond the 4G border into a VM object.
And for this VM object offset I don't see a need to be signed;
one might want to access the second half of a 64-bit memory
space through mmap(), and with a signed offset we get the same kind
of hacks as we already have in the "/dev/mem" implementations
of 32-bit ports getting an "int" offset now.

best regards
Matthias