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.
next prev parent 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).