Messages in this thread | | | Date | Thu, 23 Mar 2006 14:57:52 -0500 | From | Vivek Goyal <> | Subject | [RFC][PATCH 0/10] 64 bit resources |
| |
Hi,
Here is an attempt to implement support for 64 bit resources. This will enable memory more than 4G to be exported through /proc/iomem, which is used by kexec/kdump to determine the physical memory layout of the system.
As suggested in the last week's discussion, I picked up greg's patch and made changes on top of that.
http://www.kernel.org/pub/linux/kernel/people/gregkh/pci/2.6/2.6.11-rc3/bk-resource-2.6.11-rc3-mm1.patch
Last discussion witnessed a divided opinion upon whether to use u64 or something like dma_addr_t as data type. The argument is usage of dma_addr_t will reduce code size bloat for the people who don't want to use 64 bit resources on 32 bit platforms. But probably name dma_addr_t is not very appropriate for usage at various places.
Implementing u64 seems to be simpler and code bloat might not be significant.
This implementation is based on u64 and I have measured code bloat on i386.
- Greg's patch already had core changes. We have maninly fixed the warnings. Most of them originating from printk's().
- This patch does not try to modify the users of resources who think that on 32 bit platforms resources can be 32 bit only. They will continue to work as usual as they will silently truncate the 64 bit value to 32bit.
- We did the compilation for i386, arm, sparc, sparc64, x86_64 and ppc64 platforms and fixed the warnings.
Test Results: ------------
We used "make allyesconfig" with CONFIG_DEBUG_INFO=n on 2.6.16-mm1.
i386 ----
vmlinux size without patch: 40191425 vmlinux size with path: 40244677 vmlinux size bloat: 52K (.13%)
x86_64 ------
vmlinux size without patch: 42387898 vmlinux size with path: 42387945 vmlinux size bloat: 47 bytes
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/
| |