Messages in this thread | | | Date | Mon, 10 Jan 2005 16:28:05 -0800 | From | "Randy.Dunlap" <> | Subject | Re: clean way to support >32bit addr on 32bit CPU |
| |
Linus Torvalds wrote: > > On Mon, 10 Jan 2005, Dave wrote: > >>After all said and done, the struct resource members start and end >>must support 64bit integer values in order to work. On a 64bit arch >>that would be fine since unsigned long is 64bit. However on a 32bit >>arch one must use unsigned long long to get 64bit. > > > We really should make "struct resource" use u64's. It's wrong even on x86, > but we've never seen any real problems in practice, so we've had little > reason to bother. > > This has definitely come up before, maybe there's even some old patch > floating around. It should be as easy as just fixing up "start/end" to be > "u64" (and perhaps move them to the beginning of the struct to make sure > packing is ok on all architectures), and fixing any fall-out.
Speaking of fall-out, or more like trickle-down, I'm almost done with a patch to make PCMCIA resources use unsigned long instead of u_int or u_short for IO address:
incluce/pcmcia/cs_types.h: #if defined(__arm__) || defined(__mips__) typedef u_int ioaddr_t; #else typedef u_short ioaddr_t; #endif
becomes: typedef unsigned long ioaddr_t;
and then include/pcmcia/cs.c needs some changes in use of ioaddr_t, along with drivers (printk formats).
Does that sound OK? I guess that it would become unsigned long long (or u64) with this proposal?
-- ~Randy - 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/
| |