Messages in this thread | | | Date | Thu, 13 Jan 2005 17:28:56 -0700 | From | Dave <> | Subject | Re: [PATCH 1/5] Convert resource to u64 from unsigned long |
| |
On Thu, 13 Jan 2005 16:23:09 -0800, Andrew Morton <akpm@osdl.org> wrote: > 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. >
Ok, I shall rework the patches w/ ull. I wasn't sure that ull would cause problems on 64bit archs or not for u64....thus the ugly workarounds....
BTW, anyone know how to inline patches via gmail?
-- -= Dave =-
Software Engineer - Advanced Development Engineering Team Storage Component Division - Intel Corp. mailto://dave.jiang @ intel http://sourceforge.net/projects/xscaleiop/ ---- The views expressed in this email are mine alone and do not necessarily reflect the views of my employer (Intel Corp.). - 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/
| |