[Fwd: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK]

[Fwd: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK]

[Nick Piggin]

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 <rdreier@cisco.com>

     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.

-- 
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [Fwd: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK]

[Michael S. Tsirkin]

Quoting r. Nick Piggin <nickpiggin@yahoo.com.au>:
> 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.

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

-- 
Michael S. Tsirkin
Staff Engineer, Mellanox Technologies

Re: [Fwd: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK]

[Nick Piggin]

Michael S. Tsirkin wrote:
> Quoting r. Nick Piggin <nickpiggin@yahoo.com.au>:
> 
>>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.
> 
> 
>>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?
> 

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.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [Fwd: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK]

[Nick Piggin]

Nick Piggin wrote:

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

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [Fwd: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK]

[Michael S. Tsirkin]

Quoting r. Nick Piggin <nickpiggin@yahoo.com.au>:
> Subject: Re: [Fwd: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK]
> 
> Nick Piggin wrote:
> 
> >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?

Sounds good to me.
How about we change MADV_REMOVE to fall in this range too, then?

-- 
Michael S. Tsirkin
Staff Engineer, Mellanox Technologies

Re: [Fwd: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK]

[Russell King]

On Wed, Feb 15, 2006 at 07:17:16PM +1100, Nick Piggin wrote:
> 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.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [Fwd: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK]

[Nick Piggin]

Russell King wrote:
> On Wed, Feb 15, 2006 at 07:17:16PM +1100, Nick Piggin wrote:
> 
>>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.
> 

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

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [Fwd: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK]

[Michael S. Tsirkin]

Quoting Nick Piggin <nickpiggin@yahoo.com.au>:
> 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,

-- 
Michael S. Tsirkin
Staff Engineer, Mellanox Technologies

Re: [Fwd: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK]

[Matthew Wilcox]

On Wed, Feb 15, 2006 at 10:10:02AM +0200, Michael S. Tsirkin wrote:
> 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?

Efficiency.  GCC does much better with densely packed numbers in a
switch statement.