On Thu, Apr 21, 2016 at 08:51:04AM -0400, Rob Groner wrote: > On Thu, 2016-04-21 at 11:51 +0900, Greg KH wrote: > > On Wed, Apr 20, 2016 at 04:37:07PM -0400, Rob Groner wrote: > > > Sorry if this isn't related, it seemed like it was... > > > > > > I recently discovered one of our drivers isn't written correctly for > > > 64-bit. It uses a uint32_t to hold an address. Whoops. > > > > > > In previous drivers when I've needed to hold an address, I've used an > > > "unsigned long", as (so far as I could tell) that would give me the > > > correct number of bytes whether on 32 or 64-bit systems. > > > > > > Now that I have to fix this driver, I'd rather do whatever the > > > "standard" method is for storing an address value. > > > > > > Looking at code in the kernel and linux/types.h, I see "phys_addr_t and > > > dma_addr_t. Is that what I want to use? What if it's a virtual > > > address? void *? > > > > You want to use '__u64' and cast properly within the kernel to a > > pointer. > > > > hope this helps, > > > > greg k-h > > Thank you Greg. > > I was thinking there was a type that would hold a memory address (like > an allocated DMA buffer address, or a PCI address) that would be the > correct size on a 32-bit or 64-bit system without me having to specify a > size. If I use __u64 to hold a memory address, won't that be the wrong > size on a 32-bit system? It will be bigger than is strictly necessary in that specific case, but is that a problem? Also, please consider the case where a user is running a 32-bit userspace and a 64-bit kernel. Not making datastructures which cross the user/kernel boundaries make use of the largest fixed-width[1] type means that the kernel would have to handle this case differently (in fact, you can find many 'compat' examples in the kernel tree which do just that, because the types were incorrectly used). And, that's just terrible :(. Josh 1: Just wanted to add it's not just about size of these datatypes, either. It's about their alignment.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
