Roland Mainz wrote:
Userland. The problem is that mmap() exposed too much detail
and as a result assumptions about sysconf(_SC_PAGESIZE) or
even the range of possible values resulted in programs dying
when sysconf returns 64K for the pagesize. In other words,
the value of sysconf(_SC_PAGESIZE) has sort of defacto ended>
up baked into the Solaris ABI in an unintentional way.
... but how ? I've read the ABI specs and mmap(2) several times and the
only thing which AFAIK may be possible is trouble with MAP_FIXED and
rounding. But that's again not in the ABI, it's just that the
applications make special assumptions about the page size.
Yes, exactly. Once enough applications make assumptions about pagesize the
platform pagesize might as well have been part of the ABI.. as I recall it
was more than one application that broke, so we can't reasonable change it
now and claim to remain binary compatible.
I assume this also means a (hypothetical) SPARC CPU which only supports
16k and 256k pages cannot be supported by Solaris, right ?
Sure, there would be potential problems with that, but I would guess it
would be easier to swallow a few apps not working correctly on a new
machine as opposed to a new release of Solaris breaking compatibility on
existing hardware. But that's my personal opinion. ;) FWIW, the sun4v
specification requires CPUs to support 8K and 4M, which the Fujitsu CPUs
also support, so I would imagine there wouldn't be any deviation from
these page sizes in the forseeable future.
--
Eric Lowe Solaris Kernel Development Austin, Texas
Sun Microsystems. We make the net work. x40577/+1(512)366-9080
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
