All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Cc: dev-VfR2kkLFssw@public.gmane.org,
	Michael Qiu
	<qdy220091330-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH v3] Fix two compile issues with i686 platform
Date: Fri, 5 Dec 2014 15:02:33 +0000	[thread overview]
Message-ID: <20141205150233.GA9704@bricha3-MOBL3> (raw)
In-Reply-To: <20141205142205.GB29245-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>

On Fri, Dec 05, 2014 at 09:22:05AM -0500, Neil Horman wrote:
> On Fri, Dec 05, 2014 at 04:31:47PM +0800, Chao Zhu wrote:
> > 
> > On 2014/12/4 17:12, Michael Qiu wrote:
> > >lib/librte_eal/linuxapp/eal/eal_memory.c:324:4: error: comparison
> > >is always false due to limited range of data type [-Werror=type-limits]
> > >     || (hugepage_sz == RTE_PGSIZE_16G)) {
> > >     ^
> > >cc1: all warnings being treated as errors
> > >
> > >lib/librte_eal/linuxapp/eal/eal.c(461): error #2259: non-pointer
> > >conversion from "long long" to "void *" may lose significant bits
> > >    RTE_PTR_ALIGN_CEIL((uintptr_t)addr, RTE_PGSIZE_16M);
> > >
> > >This was introuduced by commit b77b5639:
> > >         mem: add huge page sizes for IBM Power
> > >
> > >The root cause is that size_t and uintptr_t are 32-bit in i686
> > >platform, but RTE_PGSIZE_16M and RTE_PGSIZE_16G are always 64-bit.
> > >
> > >Define RTE_PGSIZE_16G only in 64 bit platform to avoid
> > >this issue.
> > >
> > >Signed-off-by: Michael Qiu <michael.qiu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > >---
> > >  v3 ---> v2
> > >	Change RTE_PGSIZE_16G from ULL to UL
> > >	to keep all entries consistent
> > >
> > >  V2 ---> v1
> > >	Change two type entries to one, and
> > >	leave RTE_PGSIZE_16G only valid for
> > >	64-bit platform
> > >
> NACK, this is the wrong way to fix this problem.  Pagesizes are independent of
> architecutre.  While a system can't have a hugepage size that exceeds its
> virtual address limit, theres no need to do per-architecture special casing of
> page sizes here.  Instead of littering the code with ifdef RTE_ARCH_64
> everytime you want to check a page size, just convert the size_t to a uint64_t
> and you can allow all of the enumerated page types on all architecutres, and
> save yourself some ifdeffing in the process.
> 
> Neil

While I get your point, I find it distasteful to use a uint64_t for memory sizes,
when there is the size_t type defined for that particular purpose.
However, I suppose that reducing the number of #ifdefs compared to using the
"correct" datatypes for objects is a more practical optino - however distastful
I find it.

/Bruce

  parent reply	other threads:[~2014-12-05 15:02 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1417329845-7482-1-git-send-email-michael.qiu@intel.com>
     [not found] ` <1417594223-2573-1-git-send-email-michael.qiu@intel.com>
2014-12-03 11:32   ` [PATCH v2] Fix two compile issues with i686 platform Qiu, Michael
     [not found]   ` <1417594223-2573-1-git-send-email-michael.qiu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-12-03 15:40     ` Bruce Richardson
2014-12-04  2:49       ` Qiu, Michael
     [not found]         ` <533710CFB86FA344BFBF2D6802E60286C9C8C7-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-12-04  9:03           ` Thomas Monjalon
2014-12-04 10:21             ` Qiu, Michael
     [not found]               ` <533710CFB86FA344BFBF2D6802E60286C9CB12-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-12-04  9:12                 ` [PATCH v3] " Michael Qiu
2014-12-05  6:56                   ` Qiu, Michael
     [not found]                     ` <533710CFB86FA344BFBF2D6802E60286C9D074-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-12-05  7:04                       ` Chao Zhu
     [not found]                   ` <1417684369-21330-1-git-send-email-michael.qiu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-12-05  8:31                     ` Chao Zhu
     [not found]                       ` <54816D73.1020906-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2014-12-05 14:22                         ` Neil Horman
     [not found]                           ` <20141205142205.GB29245-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2014-12-05 15:02                             ` Bruce Richardson [this message]
2014-12-05 15:24                               ` Neil Horman
2014-12-08  2:46                                 ` Qiu, Michael
     [not found]                                   ` <533710CFB86FA344BFBF2D6802E60286C9D736-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-12-08  2:59                                     ` Neil Horman
2014-12-08  3:37                                       ` Qiu, Michael
2014-12-08  4:57                                         ` Qiu, Michael
     [not found]                                         ` <533710CFB86FA344BFBF2D6802E60286C9D78A-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-12-08 11:37                                           ` Neil Horman
     [not found]                                             ` <20141208113738.GA18697-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2014-12-08 11:50                                               ` Thomas Monjalon
2014-12-08 14:59                                             ` Qiu, Michael
2014-12-10 10:46                     ` [PATCH 0/2 v4] " Michael Qiu
     [not found]                       ` <1418208402-7597-1-git-send-email-michael.qiu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-12-10 10:46                         ` [PATCH 1/2 v4] Fix compile issue with hugepage_sz in 32-bit system Michael Qiu
2014-12-10 10:46                         ` [PATCH 2/2] Fix compile issue of eal with icc compile Michael Qiu
2014-12-11  0:56                         ` [PATCH 0/2 v4] Fix two compile issues with i686 platform Thomas Monjalon
2014-12-11 13:25                           ` Neil Horman
2014-12-11 15:28                             ` Qiu, Michael
     [not found]                               ` <533710CFB86FA344BFBF2D6802E60286C9EEB1-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-12-11 21:21                                 ` Thomas Monjalon
2014-12-12 11:38                                   ` Neil Horman
     [not found]                                     ` <20141212113824.GA14102-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2014-12-12 15:09                                       ` Thomas Monjalon
2014-12-12 15:29                                         ` Neil Horman

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=20141205150233.GA9704@bricha3-MOBL3 \
    --to=bruce.richardson-ral2jqcrhueavxtiumwx3w@public.gmane.org \
    --cc=dev-VfR2kkLFssw@public.gmane.org \
    --cc=nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org \
    --cc=qdy220091330-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.