Date: Thu, 12 Aug 2010 13:01:31 -0700 From: mdf@FreeBSD.org To: Ed Schouten <ed@80386.nl>, freebsd-arch@freebsd.org Subject: Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t Message-ID: <AANLkTik14mqOixxCGwJYbf5w1Y0f1zx5tmuDJwHfCMBH@mail.gmail.com> In-Reply-To: <20100812195654.GB2978@hoeg.nl> References: <AANLkTik_2pXA1LP9dq-iOLkFrQBG7jP=4yUXBjtDOBF3@mail.gmail.com> <20100812195654.GB2978@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 12, 2010 at 12:56 PM, Ed Schouten <ed@80386.nl> wrote: > Hi Matthew, > > * mdf@FreeBSD.org <mdf@FreeBSD.org> wrote: >> Looking over the arch-specific definitions, using uintptr_t and size_t >> would not affect the actual width of these sizes. =A0However, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTik14mqOixxCGwJYbf5w1Y0f1zx5tmuDJwHfCMBH>