On Sat, Apr 29, 2006 at 04:40:43PM -0700, Andrew Morton wrote:
> Vivek Goyal <[email protected]> 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.
>
How about "res_sz_t". "resource_addr_t" probably is not a very appropriate
keyword as at lots of places we also need to represent size and alignment
with this typedef.
Thanks
Vivek
On Tue, 2 May 2006 16:42:16 -0400
Vivek Goyal <[email protected]> wrote:
> > Yes, it would need to to be a new type - resource_addr_t, perhaps.
> >
>
> How about "res_sz_t".
resource_size_t, please.
> "resource_addr_t" probably is not a very appropriate
> keyword as at lots of places we also need to represent size and alignment
> with this typedef.
OK.