Skip to contentSkip to conversation

linux-libc-headers 2.6.8.1

ANNOUNCE Mariusz Mazur 5 participants 8 messages Aug 29, 2004 – Aug 30, 2004

lore
Share & tools
lore

Mariusz Mazur

author
#0 lore raw

Available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/
Changes:
- bugfix release, a couple of minor changes here and there

Nothing special, really. One bigger change - on archs that have >1 possible page sizes (PAGE_SIZE definition in asm/page.h) we're now using a call to libc's getpagesize(), so don't count on it being static on archs like ia64.

Enjoy.

Signature · 5 lines
In the year eighty five ten
God is gonna shake his mighty head
He'll either say,
"I'm pleased where man has been"
Or tear it down, and start again
#1 lore raw
Quoted 3 lines · Mariusz Mazur

Nothing special, really. One bigger change - on archs that have >1 possible page sizes (PAGE_SIZE definition in asm/page.h) we're now using a call to libc's getpagesize(), so don't count on it being static on archs like ia64.

I really do not like this change. Since PAGE_SIZE has always been a constant, the change you have made is likely to break a fair amount of code, basically any code doing stuff like:

	static int* foo[PAGE_SIZE];

Your change will result in cryptic errors such as

"error: variable-size type declared outside of any function" "error: storage size of `foo' isn't constant"

depending on whether the declaration is outside a function or in one. I think it would be much better to either

a) remove PAGE_SIZE or make using it an error somehow,

b) make PAGE_SIZE an install time config option

c) declare that on architectures such as mips that support variable PAGE_SIZE values, the libc kernel headers shall always provide the largest fixed size value of PAGE_SIZE supported for that architecture and everyone just agrees that using PAGE_SIZE rather than getpagesize(2) or sysconf(_SC_PAGESIZE) is generally a bad idea. It should be the largest value supported on that architecture, since the the only cost of always using the largest possible value is wasted ram, whereas the cost of always using the smallest value is segfaults.

With any of the above 3 suggestions, things will either just work, or the user will get a descriptive error message.

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

#2 lore raw
Quoted 3 lines · On Mon, 30 Aug 2004 00:28:56 -0600 Erik Andersen <[email protected]> wrote:

I really do not like this change. Since PAGE_SIZE has always been a constant, the change you have made is likely to break a fair amount of code, basically any code doing stuff like:

It has never been a constant, and any portable piece of software needs to evaluate it not at compile time.

When I first did the sparc64 port, the biggest source of portability problems was of the "uses PAGE_SIZE in some way" nature.

This is a positive change, we should break the build of these apps and thus get them fixed.

#3 lore raw
Quoted 10 lines · David S. Miller
Quoted 3 lines · On Mon, 30 Aug 2004 00:28:56 -0600 Erik Andersen <[email protected]> wrote:

I really do not like this change. Since PAGE_SIZE has always been a constant, the change you have made is likely to break a fair amount of code, basically any code doing stuff like:

It has never been a constant, and any portable piece of software needs to evaluate it not at compile time.

Quoted 6 lines

When I first did the sparc64 port, the biggest source of portability problems was of the "uses PAGE_SIZE in some way" nature.

This is a positive change, we should break the build of these apps and thus get them fixed.

There is no question that using PAGE_SIZE should be considered harmful. But this particular change to the linux-libc-headers makes it easy for the common case (bog standard x86) folk to keep using a fixed PAGE_SIZE value, and keep writing crap code which is now _guaranteed_ to blow chunks on mips, x86_64, etc.

I think outright removal of PAGE_SIZE from user space may be a much better choice, with some sortof #error perhaps... Wouldn't it be better for the whole world if people would get errors like

    foo.c:10:2: #error "Don't use PAGE_SIZE, use sysconf(_SC_PAGESIZE)"

making people actually fix their code?

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

#4 lore raw
Quoted 7 lines · David S. Miller
Quoted 7 lines

It has never been a constant, and any portable piece of software needs to evaluate it not at compile time. When I first did the sparc64 port, the biggest source of portability problems was of the "uses PAGE_SIZE in some way" nature.
This is a positive change, we should break the build of these apps and thus get them fixed.

Quoted 10 lines · Erik Andersen

There is no question that using PAGE_SIZE should be considered harmful. But this particular change to the linux-libc-headers makes it easy for the common case (bog standard x86) folk to keep using a fixed PAGE_SIZE value, and keep writing crap code which is now _guaranteed_ to blow chunks on mips, x86_64, etc. I think outright removal of PAGE_SIZE from user space may be a much better choice, with some sortof #error perhaps... Wouldn't it be better for the whole world if people would get errors like

    foo.c:10:2: #error "Don't use PAGE_SIZE, use sysconf(_SC_PAGESIZE)"

making people actually fix their code?

In general people #define PAGE_SIZE (getpagesize()) or some such.

-- wli

#5 lore raw
Quoted 21 lines · William Lee Irwin III
Quoted 7 lines · David S. Miller
Quoted 7 lines

It has never been a constant, and any portable piece of software needs to evaluate it not at compile time. When I first did the sparc64 port, the biggest source of portability problems was of the "uses PAGE_SIZE in some way" nature.
This is a positive change, we should break the build of these apps and thus get them fixed.

Quoted 10 lines · Erik Andersen

There is no question that using PAGE_SIZE should be considered harmful. But this particular change to the linux-libc-headers makes it easy for the common case (bog standard x86) folk to keep using a fixed PAGE_SIZE value, and keep writing crap code which is now _guaranteed_ to blow chunks on mips, x86_64, etc. I think outright removal of PAGE_SIZE from user space may be a much better choice, with some sortof #error perhaps... Wouldn't it be better for the whole world if people would get errors like

    foo.c:10:2: #error "Don't use PAGE_SIZE, use sysconf(_SC_PAGESIZE)"

making people actually fix their code?

Quoted 1 line

In general people #define PAGE_SIZE (getpagesize()) or some such.

Then perhaps the right thing is for linux-libc-headers to always provide such a define for PAGE_SIZE for _all_ architectures, not just for those that happen to have variable PAGE_SIZE values.

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

author
#6 lore raw
In reply to Erik Andersen
Quoted 5 lines · Erik Andersen

There is no question that using PAGE_SIZE should be considered harmful. But this particular change to the linux-libc-headers makes it easy for the common case (bog standard x86) folk to keep using a fixed PAGE_SIZE value, and keep writing crap code which is now _guaranteed_ to blow chunks on mips, x86_64, etc.

Good point. I'll switch to using getpagesize() everywhere in a release or two.

Signature · 5 lines
In the year eighty five ten
God is gonna shake his mighty head
He'll either say,
"I'm pleased where man has been"
Or tear it down, and start again