[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <787b0d920707141948t71b4059s7ae68610f9f81eac@mail.gmail.com>
Date: Sat, 14 Jul 2007 22:48:57 -0400
From: "Albert Cahalan" <acahalan@...il.com>
To: olaf@...fle.de, hpa@...or.com, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] remove PAGE_SIZE from headers_install
Olaf Hering writes:
> On Sat, Jul 14, H. Peter Anvin wrote:
>> Olaf Hering wrote:
>>> Declare PAGE_SIZE as getpagesize() for userspace.
>>> PAGE_SIZE is used in resource.h and shm.h
>>
>> I would think it would be better to not define it at all.
>> Several architectures already don't have PAGE_SIZE visible
>> to userspace in any way.
>
> i386 has it, so everyone uses it.
Since i386 was the first architecture and is still probably the
most common architecture (x86_64 being 30% AFAIK), i386 sets the
standard for the Linux API. Several architectures are broken and
thus suffering from incompatibility.
A real constant-value PAGE_SIZE is useful and doable.
It's useful because a getpagesize() can't be used for numerous
things, such as setting the size of an array.
It's doable, even on architectures that support multiple page
sizes, because ABIs specify alignment requirements. There are
two alignments of interest here:
a. the smallest that mmap() will ever naturally return on any
correct implementation of the architecture's ABI ("naturally"
meaning that MAP_FIXED was not used)
b. the smallest that mprotect() will tolerate on all
correct implementations of the architecture
Pick either to be the Linux definition of PAGE_SIZE.
For example, if an architecture is specified to have a page size
of at least 4 K but no more than 64 K, then mprotect() will only
tolerate 64 K on all correct implementations of the architecture.
The ABI might allow mmap() to naturally return 4 K aligned data,
but might instead require 64 K alignment. Assuming 4 K, then the
mmap() value doesn't match the mprotect() value. Either one will
do as the value of PAGE_SIZE, as long as this is standardized in
the way that breaks the least code.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists