mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, jbarnes@engr.sgi.com
Subject: Re: [PATCH] don't pass mem_map into init functions
Date: Wed, 4 Aug 2004 21:42:50 -0700	[thread overview]
Message-ID: <20040804214250.2de3dd81.akpm@osdl.org> (raw)
In-Reply-To: <1091581282.27397.6676.camel@nighthawk>

Dave Hansen <haveblue@us.ibm.com> wrote:
>
> When using CONFIG_NONLINEAR, a zone's mem_map isn't contiguous, and
>  isn't allocated in the same place.  This means that nonlinear doesn't
>  really have a mem_map[] to pass into free_area_init_node() or 
>  memmap_init_zone() which makes any sense.  
> 
>  So, this patch removes the 'struct page *mem_map' argument to both of
>  those functions.  All non-NUMA architectures just pass a NULL in there,
>  which is ignored.  The solution on the NUMA arches is to pass the
>  mem_map in via the pgdat, which works just fine. 
> 
>  To replace the removed arguments, a call to pfn_to_page(node_start_pfn)
>  is made.  This is valid because all of the pfn_to_page() implementations
>  rely only on the pgdats, which are already set up at this time.  Plus,
>  the pfn_to_page() method should work for any future nonlinear-type
>  code.  
> 
>  Finally, the patch creates a function: node_alloc_mem_map(), which I
>  plan to effectively #ifdef out for nonlinear at some future date.  

You wanna take a shot at fixing this up please?

arch/sparc64/mm/init.c: In function `paging_init':
arch/sparc64/mm/init.c:1589: warning: passing arg 4 of `free_area_init_node' makes integer from pointer without a cast
arch/sparc64/mm/init.c:1589: warning: passing arg 5 of `free_area_init_node' makes pointer from integer without a cast
arch/sparc64/mm/init.c:1589: error: too many arguments to function `free_area_init_node'


  parent reply	other threads:[~2004-08-05  4:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-04  1:01 Dave Hansen
2004-08-04 18:48 ` Jesse Barnes
2004-08-05  4:42 ` Andrew Morton [this message]
2004-08-05 18:55   ` Dave Hansen
2004-08-05 21:13 ` Andrew Morton
2004-08-05 23:58   ` Dave Hansen
  -- strict thread matches above, loose matches on Subject: below --
2004-07-28 20:55 Dave Hansen
2004-07-28 21:58 ` Jesse Barnes
2004-07-28 22:01 ` Jesse Barnes
2004-07-28 22:19   ` Dave Hansen
2004-07-28 22:39     ` Jesse Barnes
2004-07-28 23:18       ` Dave Hansen
2004-07-29  1:33         ` Jesse Barnes
2004-07-29 23:10         ` Dave Hansen
2004-07-30 14:29           ` Martin J. Bligh

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=20040804214250.2de3dd81.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=haveblue@us.ibm.com \
    --cc=jbarnes@engr.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome