All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	ebmunson@us.ibm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-man@vger.kernel.org,
	mtk.manpages@gmail.com, randy.dunlap@oracle.com, rth@twiddle.net,
	ink@jurassic.park.msu.ru, Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	linux-ia64@vger.kernel.org
Subject: Re: [PATCH] remove duplicate asm/mman.h files
Date: Mon, 21 Sep 2009 08:31:25 +0000	[thread overview]
Message-ID: <200909211031.25369.arnd@arndb.de> (raw)
In-Reply-To: <alpine.DEB.1.00.0909181236190.27556@chino.kir.corp.google.com>

On Friday 18 September 2009, David Rientjes wrote:
> On Fri, 18 Sep 2009, Arnd Bergmann wrote:
>
> > -#define MCL_CURRENT	1		/* lock all current mappings */
> > -#define MCL_FUTURE	2		/* lock all future mappings */
> > +#define MAP_GROWSUP	0x0200		/* register stack-like segment */
> >  
> >  #ifdef __KERNEL__
> >  #ifndef __ASSEMBLY__
> 
> ia64 doesn't use MAP_GROWSUP, so it's probably not necessary to carry it 
> along with your cleanup.

ia64 is the only architecture defining it, nobody uses it in the kernel.
If the ia64 maintainers want to remove it in a separate patch, that
would probably be a good idea.

I tried not to change the ABI in any way in my patch, and there is
a theoretical possibility that some user space program on ia64 currently
depends on that definition.

	Arnd <><

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	ebmunson@us.ibm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-man@vger.kernel.org,
	mtk.manpages@gmail.com, randy.dunlap@oracle.com, rth@twiddle.net,
	ink@jurassic.park.msu.ru, Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	linux-ia64@vger.kernel.org
Subject: Re: [PATCH] remove duplicate asm/mman.h files
Date: Mon, 21 Sep 2009 10:31:25 +0200	[thread overview]
Message-ID: <200909211031.25369.arnd@arndb.de> (raw)
In-Reply-To: <alpine.DEB.1.00.0909181236190.27556@chino.kir.corp.google.com>

On Friday 18 September 2009, David Rientjes wrote:
> On Fri, 18 Sep 2009, Arnd Bergmann wrote:
>
> > -#define MCL_CURRENT	1		/* lock all current mappings */
> > -#define MCL_FUTURE	2		/* lock all future mappings */
> > +#define MAP_GROWSUP	0x0200		/* register stack-like segment */
> >  
> >  #ifdef __KERNEL__
> >  #ifndef __ASSEMBLY__
> 
> ia64 doesn't use MAP_GROWSUP, so it's probably not necessary to carry it 
> along with your cleanup.

ia64 is the only architecture defining it, nobody uses it in the kernel.
If the ia64 maintainers want to remove it in a separate patch, that
would probably be a good idea.

I tried not to change the ABI in any way in my patch, and there is
a theoretical possibility that some user space program on ia64 currently
depends on that definition.

	Arnd <><

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	ebmunson@us.ibm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-man@vger.kernel.org,
	mtk.manpages@gmail.com, randy.dunlap@oracle.com, rth@twiddle.net,
	ink@jurassic.park.msu.ru, Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	linux-ia64@vger.kernel.org
Subject: Re: [PATCH] remove duplicate asm/mman.h files
Date: Mon, 21 Sep 2009 10:31:25 +0200	[thread overview]
Message-ID: <200909211031.25369.arnd@arndb.de> (raw)
In-Reply-To: <alpine.DEB.1.00.0909181236190.27556@chino.kir.corp.google.com>

On Friday 18 September 2009, David Rientjes wrote:
> On Fri, 18 Sep 2009, Arnd Bergmann wrote:
>
> > -#define MCL_CURRENT	1		/* lock all current mappings */
> > -#define MCL_FUTURE	2		/* lock all future mappings */
> > +#define MAP_GROWSUP	0x0200		/* register stack-like segment */
> >  
> >  #ifdef __KERNEL__
> >  #ifndef __ASSEMBLY__
> 
> ia64 doesn't use MAP_GROWSUP, so it's probably not necessary to carry it 
> along with your cleanup.

ia64 is the only architecture defining it, nobody uses it in the kernel.
If the ia64 maintainers want to remove it in a separate patch, that
would probably be a good idea.

I tried not to change the ABI in any way in my patch, and there is
a theoretical possibility that some user space program on ia64 currently
depends on that definition.

	Arnd <><

  reply	other threads:[~2009-09-21  8:31 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-25 11:14 [PATCH 0/3] Add pseudo-anonymous huge page mappings V4 Eric B Munson
2009-08-25 11:14 ` [PATCH 1/3] hugetlbfs: Allow the creation of files suitable for MAP_PRIVATE on the vfs internal mount Eric B Munson
2009-08-26 19:34   ` David Rientjes
2009-08-26 19:34     ` David Rientjes
2009-08-25 11:14 ` [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Eric B Munson
2009-09-17 22:44   ` Andrew Morton
2009-09-17 22:44     ` Andrew Morton
2009-09-17 22:44     ` Andrew Morton
2009-09-18  0:46     ` Andrew Morton
2009-09-18  0:46       ` Andrew Morton
2009-09-18  0:46       ` Andrew Morton
2009-09-18 15:19       ` [PATCH] " Arnd Bergmann
2009-09-18 15:19         ` Arnd Bergmann
     [not found]         ` <200909181719.47240.arnd-r2nGTMty4D4@public.gmane.org>
2009-09-18 16:48           ` [PATCH] remove duplicate asm/mman.h files Arnd Bergmann
2009-09-18 16:48             ` Arnd Bergmann
2009-09-18 16:48             ` Arnd Bergmann
     [not found]             ` <200909181848.42192.arnd-r2nGTMty4D4@public.gmane.org>
2009-09-18 19:37               ` David Rientjes
2009-09-18 19:37                 ` David Rientjes
2009-09-18 19:37                 ` David Rientjes
2009-09-21  8:31                 ` Arnd Bergmann [this message]
2009-09-21  8:31                   ` Arnd Bergmann
2009-09-21  8:31                   ` Arnd Bergmann
2009-09-21  9:13                   ` David Rientjes
2009-09-21  9:13                     ` David Rientjes
2009-09-21  9:13                     ` David Rientjes
2009-09-21  9:30                     ` Arnd Bergmann
2009-09-21  9:30                       ` Arnd Bergmann
2009-09-21  9:30                       ` Arnd Bergmann
2009-09-21 12:02                     ` Hugh Dickins
2009-09-21 12:02                       ` Hugh Dickins
2009-09-21 12:02                       ` Hugh Dickins
2009-09-21 12:02                       ` Hugh Dickins
2009-09-21 22:55                       ` David Rientjes
2009-09-21 22:55                         ` David Rientjes
2009-09-21 22:55                         ` David Rientjes
2009-09-21 23:25                         ` Luck, Tony
2009-09-21 23:25                           ` Luck, Tony
2009-09-21 23:25                           ` Luck, Tony
2009-09-21 23:46                           ` David Rientjes
2009-09-21 23:46                             ` David Rientjes
2009-09-21 23:46                             ` David Rientjes
2009-09-21 23:58                             ` Ulrich Drepper
2009-09-21 23:58                               ` Ulrich Drepper
2009-09-21 23:58                               ` Ulrich Drepper
2009-09-21 23:58                               ` Ulrich Drepper
2009-09-21 12:27             ` Eric B Munson
2009-09-21 12:25         ` [PATCH] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Eric B Munson
2009-08-25 11:14 ` [PATCH 3/3] Add MAP_HUGETLB example Eric B Munson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200909211031.25369.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=akpm@linux-foundation.org \
    --cc=ebmunson@us.ibm.com \
    --cc=fenghua.yu@intel.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mtk.manpages@gmail.com \
    --cc=randy.dunlap@oracle.com \
    --cc=rientjes@google.com \
    --cc=rth@twiddle.net \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.