Re: [PATCH] catch valid mem range at onlining memory

[Andrew Morton]

Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
>
> > > All the code bloat's a bit sad though.  It would have been nice to have
> > > made the type of resource.start and .end Kconfigurable.  What happened
> > > to that?
> > 
> > Hm, I didn't remember anything about that.  Vivek, any thoughts?
> >
> 
> Having resource size configurable is nice but it brings added complexity
> with it. The question would be if code bloat is significant enough to 
> go for other option. Last time I had posted few compilation results on
> i386. I am summarizing these again.
> 
> allmodconfig (CONFIG_DEBUG_INFO=n)
> -----------
> 
> vmlinux bloat:4096 bytes
> 
> allyesconfig  (CONFIG_DEBUG_INFO=n)
> -----------
>                                                                                 
> vmlinux size bloat: 52K
> 
> So even with allyesconfig total bloat is 52K and I am assuming the
> systems where memory is at premium are going to use a very limited set
> of modules and effectively will see much lesser code bloat than 52K.
> 
> For Kconfigurable resource size, probably dma_addr_t is not the very 
> appropriate as at lots of places size also needs to be 64 bit and 
> using dma_addr_t is not good. This will then boil down to introducing
> a new type like dma_addr_t whose size is Kconfigurable.

Yes, it would need to to be a new type - resource_addr_t, perhaps.

> Even if it is done, it will not get rid of code bloat completely as lots
> of code bloat comes from printk() statemets where we explicitly typecast
> the resource to (unsigned long long) to avoid compilation warnings across
> the platforms. This typecasting will continue to be there even with
> Kconfigurable resources.

True.

But you know, just because a printk is present doesn't actually mean that
it's useful.

IOW, the default should be to just delete the printks (or the
resource.start/end parts of them), and to grudgingly put them back if
someone screams loudly enough.  We have other ways of viewing the
iomem_resource and ioport_resource trees.

> Personally I would tend to think that we can live with this code bloat.

Every little bit counts ;) We tend to be a bit obsessive about this, but I
think it's good, although perhaps wasteful of developer time..

I wouldn't view any of this as blocking the present patches.  It's
a separable project.
-
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/