single, comprehensive kernel data types document?

[Greg KH]

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?

As Josh says, this is fine, you just "burn" 4 bytes, but you need to do
that anyway for alignment and you save for not having a 'compat ioctl'
callback to do the pointer fixup that would be required if you were to
use a 32bit value for a pointer.

And also, as Josh says, consider mixed user/kernel sizes, that gets
messy very quickly, so just always make pointers 64bits and all works
just fine.

hope this helps,

greg k-h