RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t

[mdf at FreeBSD.org]

On Thu, Aug 12, 2010 at 12:56 PM, Ed Schouten <ed at 80386.nl> wrote:
> Hi Matthew,
>
> * mdf at FreeBSD.org <mdf at FreeBSD.org> wrote:
>> Looking over the arch-specific definitions, using uintptr_t and size_t
>> would not affect the actual width of these sizes.  However, it would
>> simplify e.g. conformant printf(9) statements, since there is an
>> approved specifier for size_t and, while there isn't one for
>> uintptr_t, ptrdiff_t is pretty close (Bruce, is there a better
>> specifier)?
>
> Not that I know any architecture we support which does this, but what
> happens if userspace has a larger address space than kernelspace? Say,
> we ever have some kind of architecture with a 32-bit kernel running
> 64-bit userspace applications.

True, in that instance 32-bit types wouldn't work.  However, there is
a *lot* of vm work needed to support 64 bit apps on a 32-bit kernel,
and I really doubt there will be any investment in this for any of the
32-bit architectures.  We had such a setup on AIX until the 32-bit
kernel was killed, to support applications that needed more than 4GB
before IBM was ready to do the 64-bit kernel project.  Such a setup
requires running on 64-bit hardware, and for whatever reason choosing
to use the 32-bit kernel.  I also can't think of any compelling reason
to use a 32-bit kernel when a 64-bit one is available.

Thanks,
matthew