Messages in this thread | | | Date | Thu, 13 Jan 2005 16:23:09 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 1/5] Convert resource to u64 from unsigned long |
| |
Dave <dave.jiang@gmail.com> wrote: > > ere's my first attempt of trying to convert the struct resource > start/end to u64 per blessed by Linus =) This is to support >32bit > physical address on 32bit archs such as some of the newer ARMv6 and > XSC3 based platforms and perhaps IA32 PAE. I left the PCI stuff alone > functionally. Supporting 64bit PCI BAR on 32bit archs is for another > day. I fixed most of the core stuff I can think of, fixed ARM and i386 > hopefully and a few of the device drivers as examples. I have tested > on an IQ31244 XScale IOP (ARM) platform and a dual-xeon platform for > i386. Matt Porter has graciously sent me PPC fixes that he tested on.
OK, well Greg KH will be the main target of this work..
Can you do something a bit more friendly than application/octet-stream encoding, btw?
+#if BITS_PER_LONG == 64 +#define U64FMT "016lx" +#else +#define U64FMT "016Lx" +#endif
We've avoided doing this. We prefer to do
printk("%llx", (unsigned long long)foo);
which is tidier, although a little more runtime-costly.
Your approach assumes that all 64-bit architectures implement u64 as unsigned long (as opposed to unsigned long long, which I guess is legal?) I don't know if that's a problem or not.
Also, the patches introduce tons of ifdefs such as:
+#if BITS_PER_LONG == 64 return (void __iomem *)pci_resource_start(pdev, PCI_ROM_RESOURCE); +#else + return (void __iomem *)(u32)pci_resource_start(pdev, PCI_ROM_RESOURCE); +#endif
We really should find a way of avoiding this. Even if it is
#if BITS_PER_LONG == 64 #define resource_to_ptr(r) ((void *)(r)) #else #define resource_to_ptr(r) ((void *)((u32)r)) #endif
in a header file somewhere. Open-coding the decision all over the place is unsightly.
- 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/
| |