[ANNOUNCE] linux-libc-headers 2.6.8.1

[ANNOUNCE] linux-libc-headers 2.6.8.1

[Mariusz Mazur]

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.

-- 
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

Re: [ANNOUNCE] linux-libc-headers 2.6.8.1

[Erik Andersen]

On Sun Aug 29, 2004 at 10:32:13PM +0200, Mariusz Mazur wrote:
> 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--

Re: [ANNOUNCE] linux-libc-headers 2.6.8.1

[David S. Miller]

On Mon, 30 Aug 2004 00:28:56 -0600
Erik Andersen <andersen@codepoet.org> 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.

Re: [ANNOUNCE] linux-libc-headers 2.6.8.1

[Erik Andersen]

On Mon Aug 30, 2004 at 12:24:22AM -0700, David S. Miller wrote:
> On Mon, 30 Aug 2004 00:28:56 -0600
> Erik Andersen <andersen@codepoet.org> 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.

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--

Re: [ANNOUNCE] linux-libc-headers 2.6.8.1

[William Lee Irwin III]

On Mon Aug 30, 2004 at 12:24:22AM -0700, David S. Miller wrote:
>> 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.

On Mon, Aug 30, 2004 at 01:48:35AM -0600, Erik Andersen wrote:
> 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

Re: [ANNOUNCE] linux-libc-headers 2.6.8.1

[Erik Andersen]

On Mon Aug 30, 2004 at 01:07:57AM -0700, William Lee Irwin III wrote:
> On Mon Aug 30, 2004 at 12:24:22AM -0700, David S. Miller wrote:
> >> 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.
> 
> On Mon, Aug 30, 2004 at 01:48:35AM -0600, Erik Andersen wrote:
> > 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.

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--

Re: [ANNOUNCE] linux-libc-headers 2.6.8.1

[Mariusz Mazur]

On poniedziałek 30 sierpień 2004 09:48, Erik Andersen wrote:
> 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.

-- 
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

Re: [ANNOUNCE] linux-libc-headers 2.6.8.1

[Andrew Walrond]

On Sunday 29 Aug 2004 21:32, Mariusz Mazur wrote:
> Available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/
> Changes:
> - bugfix release, a couple of minor changes here and there
>
Just some positive feedback; thanks for this project. It has become a vital 
and (dare I say it) trusted component of my work. Long may it continue :)

Andrew Walrond

Re: [ANNOUNCE] linux-libc-headers 2.6.8.1

[Albert Cahalan]

Erik Andersen writes:
> On Sun Aug 29, 2004 at 10:32:13PM +0200, Mariusz Mazur wrote:

>> 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];
 
SuSE has already done this, so it's nothing new.

> 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"
 
You'll get a line number too. At least it's a compile-time
error, instead of a quiet data-corrupting run-time error.

> 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,
 
Nope. That breaks more code than necessary.

>     b) make PAGE_SIZE an install time config option
 
Nope. Executables need to run on multiple kernels.

>     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

Nope. This is silent data corruption.

You'll break stuff like this:   P_rss *= (PAGE_SIZE/1024);