Re: [PATCH 28/31] memblock: Export MEMBLOCK_ERROR again

[Benjamin Herrenschmidt]

On Wed, 2010-07-28 at 15:15 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2010-07-22 at 11:21 -0700, Yinghai Lu wrote:
> > will used by x86 memblock_x86_find_in_range_node and nobootmem replacement
> > 
> > -v2: use 0 instead -1ULL, Suggested by Linus, so we don't need cast them later to unsigned long
> 
> The patch in its current form is a NAK.
> 
> You can't just do those two things in one commit.
> 
> If we're going to switch LMB errors to always be 0, we need to ensure we
> cannot realistically hand out 0 as a result of lmb_alloc().
> 
> I'll cook up a patch to do that.

BTW. After that, maybe send a patch completely removing
MEMBLOCK_ERROR ? 

I find 0 to be self-explanatory enough.

Cheers,
Ben.

> Ben.
> 
> > Signed-off-by: Yinghai Lu <yinghai@xxxxxxxxxx>
> > ---
> >  include/linux/memblock.h |    1 +
> >  mm/memblock.c            |    2 --
> >  2 files changed, 1 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > index 70bc467..89749c4 100644
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -19,6 +19,7 @@
> >  #include <asm/memblock.h>
> >  
> >  #define INIT_MEMBLOCK_REGIONS 128
> > +#define MEMBLOCK_ERROR		0
> >  
> >  struct memblock_region {
> >  	phys_addr_t base;
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 796ef8c..3d0a754 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -27,8 +27,6 @@ int memblock_can_resize;
> >  static struct memblock_region memblock_memory_init_regions[INIT_MEMBLOCK_REGIONS + 1];
> >  struct memblock_region memblock_reserved_init_regions[INIT_MEMBLOCK_REGIONS + 1];
> >  
> > -#define MEMBLOCK_ERROR	(~(phys_addr_t)0)
> > -
> >  /* inline so we don't get a warning when pr_debug is compiled out */
> >  static inline const char *memblock_type_name(struct memblock_type *type)
> >  {
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/