kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: me@tobin.cc (Tobin C. Harding)
To: kernelnewbies@lists.kernelnewbies.org
Subject: generic memory addresses
Date: Thu, 6 Apr 2017 20:11:34 +1000	[thread overview]
Message-ID: <20170406101134.GI18834@eros> (raw)
In-Reply-To: <20170406060820.GA9759@kroah.com>

On Thu, Apr 06, 2017 at 08:08:20AM +0200, Greg KH wrote:
> On Thu, Apr 06, 2017 at 10:31:01AM +1000, Tobin C. Harding wrote:
> > Why is there code in-tree that declares generic memory addresses as
> > unsigned int?
> > 
> > Linux Device Drivers 3rd Edition page 289
> >  Therefore, generic memory addresses in the kernel are usually unsigned
> >  long, exploiting the fact that pointers and long integers are always
> >  the same size, at least on all the platforms currently supported by
> >  Linux.
> > 
> > It would therefore seem like a bug to declare a generic memory address
> > as an unsigned int in code that can run on 64 bit machines.
> 
> I agree, that does seem like a bug.

The example that started me looking at this is in
drivers/mmc/core/sdio_io.c

int sdio_memcpy_fromio(struct sdio_func *func, void *dst,
	unsigned int addr, int count)
{
	return sdio_io_rw_ext_helper(func, 0, addr, 1, dst, count);
}

Is there perhaps some reason that it can be guaranteed that this
address is for 32 bit architecture. Is it acceptable to think that mmc
cards are never more than 32 bit and this code will never have its use
extended to where 64 bit addresses are used?

> > What is the explanation for such declarations in the kernel please?
> > 
> > $ cd KERNEL_TREE
> > $ git grep 'unsigned int addr' | wc -l
> > 556
> 
> Make sure those really are being used to store a real address, sometimes
> they are not...

righto.

thanks,
Tobin.

  reply	other threads:[~2017-04-06 10:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-06  0:31 generic memory addresses Tobin C. Harding
2017-04-06  6:08 ` Greg KH
2017-04-06 10:11   ` Tobin C. Harding [this message]
2017-04-06 16:59     ` Greg KH
2017-04-06 22:02       ` Tobin C. Harding

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170406101134.GI18834@eros \
    --to=me@tobin.cc \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).