Messages in this thread | | | Date | Tue, 2 May 2006 16:42:16 -0400 | From | Vivek Goyal <> | Subject | Re: [PATCH] catch valid mem range at onlining memory |
| |
On Sat, Apr 29, 2006 at 04:40:43PM -0700, Andrew Morton wrote: > Vivek Goyal <vgoyal@in.ibm.com> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |