madvise MADV_DONTFORK/MADV_DOFORK]
PATCH 1/1 madvise MADV_DONTFORK/MADV_DOFORK]
Forwarding to linux-arch. Please pipe up on lkml, or send patches to fix your arch (either way, before 2.6.16!!) if you disagree.
To me it would be more logical if the numbering was made densely packed on all architectures even if that means MADV_DONTFORK / DOFORK aren't consistently numbered throughout (why should they get special treatment?).
Nick
-------- Original Message --------
Subject: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK
Date: Tue, 14 Feb 2006 22:09:34 -0800
From: Roland Dreier <[email protected]>
Nick> May I ask, what is the rationale for ignoring the apparent Nick> conventions of all architectures? For example parisc, you Nick> appear to even go contrary to the comment.
Looking through include/asm-*/mman.h, I have to agree. The parisc example seemly especially bad, as (in addition to being in the reserved range as Nick notes) the DONTFORK/DOFORK values are stuck in a block with the page size values instead of the previous block where they seem more sensible. However, in other files like the alpha version, where the rest of the values are in decimal, the hex defines look rather jarring.
Michael, what led you to choose 0x30 and 0x31 for the two new values? It does seem that keeping them uniform across architectures is a reasonable thing to do, but as far as I can tell the values 9 and 10 are unused on all architectures, and have the added merit of not falling in the parisc reserved range.
Do we still have a chance to change this?
- R.
Signature · 1 line
Send instant messages to your online friends http://au.messenger.yahoo.com
Quoting r. Nick Piggin <[email protected]>:
Quoted 4 lines
Subject: [Fwd: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK]
Forwarding to linux-arch. Please pipe up on lkml, or send patches to fix your arch (either way, before 2.6.16!!) if you disagree.
I plan to move them to 9, 10 as Roland suggested.
Quoted 4 lines
To me it would be more logical if the numbering was made densely packed on all architectures even if that means
MADV_DONTFORK/ DOFORK aren't consistently numbered throughout (why should they get special treatment?).
Making the values identical on all architectures makes it possible to write a portable application even before distributions update their headers. Thats important to me.
I assume that the values are different on different architectures because of legacy/backward compatibility concerns, but I dont see compelling reasons to mess up new values.
Why is it important to keep the MADV_ numbers densely packed? We have 32 bit for these, dont we?
What am I missing?
Signature · 2 lines
Michael S. Tsirkin Staff Engineer, Mellanox Technologies
Quoted 21 lines · Michael S. Tsirkin
Quoting r. Nick Piggin <[email protected]>:
Quoted 4 lines
Subject: [Fwd: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK]
Forwarding to linux-arch. Please pipe up on lkml, or send patches to fix your arch (either way, before 2.6.16!!) if you disagree.
I plan to move them to 9, 10 as Roland suggested.
Quoted 4 lines
To me it would be more logical if the numbering was made densely packed on all architectures even if that means
MADV_DONTFORK/ DOFORK aren't consistently numbered throughout (why should they get special treatment?).Making the values identical on all architectures makes it possible to write a portable application even before distributions update their headers. Thats important to me.
Quoted 8 lines
I assume that the values are different on different architectures because of legacy/backward compatibility concerns, but I dont see compelling reasons to mess up new values.
Why is it important to keep theMADV_numbers densely packed? We have 32 bit for these, dont we?What am I missing?
All I'm saying is that we can easily wait a few days until arch maintainers have had a chance to comment (you didn't think you were missing anything last time, either).
We can afford to be a little bit careful about changing user APIs.
Signature · 2 lines
SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
Quoted 5 lines · Nick Piggin
All I'm saying is that we can easily wait a few days until arch maintainers have had a chance to comment (you didn't think you were missing anything last time, either).
We can afford to be a little bit careful about changing user APIs.
The new numbers only appeared very recently for ARM (iow, came in with this mornings git update), so changing them sooner rather than later would be preferred - cuts down the number of potential kernel patches/tarballs which have the "wrong" numbers.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
Quoted 6 lines · Russell King
Quoted 4 lines · Nick Piggin
All I'm saying is that we can easily wait a few days until arch maintainers have had a chance to comment (you didn't think you were missing anything last time, either).
Quoted 8 lines
Quoted 1 line
We can afford to be a little bit careful about changing user APIs.
The new numbers only appeared very recently for ARM (iow, came in with this mornings git update), so changing them sooner rather than later would be preferred - cuts down the number of potential kernel patches/tarballs which have the "wrong" numbers.
I just mean, to get an agreement (or at least nobody complaining) before renumbering it again.
I don't think it should be too much of a problem unless it hits 2.6.16 (2.6.16-rc4 would be undesirable too I guess).
Signature · 2 lines
SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
Quoting Nick Piggin <[email protected]>:
Quoted 5 lines
All I'm saying is that we can easily wait a few days until arch maintainers have had a chance to comment (you didn't think you were missing anything last time, either).
We can afford to be a little bit careful about changing user APIs.
I agree. Most people dont seem to notice stuff until its in -mm, so it makes sense for this code to stay in -mm for a few days.
Thanks,
Signature · 2 lines
Michael S. Tsirkin Staff Engineer, Mellanox Technologies
Quoted 6 lines · Nick Piggin
All I'm saying is that we can easily wait a few days until arch maintainers have had a chance to comment (you didn't think you were missing anything last time, either).
We can afford to be a little bit careful about changing user APIs.
If it is a good idea to keep the common MADV_ parameters in synch over all architectures, why not make 0x00 - 0xff the legacy space, then 0x100 - 0xfff can be for arch specific parameters, and 0x1000 - ... can be for common/generic parameters?
Signature · 2 lines
SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
Quoting r. Nick Piggin <[email protected]>:
Quoted 8 lines
Subject: Re: [Fwd: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK]
Quoted 4 lines · Nick Piggin
All I'm saying is that we can easily wait a few days until arch maintainers have had a chance to comment (you didn't think you were missing anything last time, either).
Quoted 7 lines
Quoted 2 lines
We can afford to be a little bit careful about changing user APIs.
If it is a good idea to keep the common
MADV_parameters in synch over all architectures, why not make0x00-0xffthe legacy space, then0x100-0xfffcan be for arch specific parameters, and0x1000- ... can be for common/generic parameters?
Sounds good to me.
How about we change MADV_REMOVE to fall in this range too, then?
Signature · 2 lines
Michael S. Tsirkin Staff Engineer, Mellanox Technologies
Quoted 5 lines · Michael S. Tsirkin
I assume that the values are different on different architectures because of legacy/backward compatibility concerns, but I dont see compelling reasons to mess up new values.
Why is it important to keep theMADV_numbers densely packed? We have 32 bit for these, dont we?
Efficiency. GCC does much better with densely packed numbers in a switch statement.