public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Hal Rosenstock
	<hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>,
	Jason Gunthorpe
	<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>,
	Jarod Wilson <jarod-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH rdma-core] redhat/spec: can't build ibumad on 32-bit arm
Date: Tue, 10 Jan 2017 12:36:04 -0500	[thread overview]
Message-ID: <1484069764.2149.18.camel@redhat.com> (raw)
In-Reply-To: <a1b3f6cc-2de0-8a19-18dd-182f2cb7d3e1-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2260 bytes --]

On Tue, 2017-01-10 at 11:30 -0500, Hal Rosenstock wrote:
> On 1/9/2017 5:31 PM, Jason Gunthorpe wrote:
> > 
> > On Mon, Jan 09, 2017 at 04:39:44PM -0500, Jarod Wilson wrote:
> > > 
> > > Building for 32-bit arm, things fall down, due to lack of arch-
> > > specific
> > > memory barriers.
> > 
> > Since we now have rxe that should work on ARM I think we need to
> > fix
> > this upstream..
> > 
> > Do you have time to test some patches on ARM?
> 
> Looks to me that issue was introduced by:
> 
> commit 1df0888f6a736e1612ce8b054d6c17651ebd003f
> Author: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> Date:   Fri Sep 2 12:57:57 2016 -0600
> 
>     Remove most checks of __BYTE_ORDER
> 
>     For a long time now endian.h has defined sane fixed with
> conversion
>     macros, so lets just use them instead of rolling our own.
> 
>     Also, htonll is defined in this source tree under
> infiniband/arch.h,
>     so all users of that macro can just use the header.
> 
>     Someday we should also get rid of all the endless wrappers..
> 
>     Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> 
> where byte order macros are from libibverbs arch.h which also
> includes
> the memory barrier stuff.
> 
> So can't arch.h be separated out into 2 headers and have the various
> parts of rdma-core include one or both of these headers as needed ?

No, that won't help.  At most it would shift where the compile breaks.
 When Steve Wise did the patch to add the arm64 memory barriers, we
discussed on list the fact that not having a proper memory barrier
define for an arch should be a fatal error, so we also made it such
that without an arch specific memory barrier define, we fail the build.
 If you split the headers, then somewhere you are going to come to a
file that needs the memory barriers defined in the headers, and when
you include the header, the compile error returns.  The proper fix is
just to get 32bit arm defines in place.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2017-01-10 17:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-09 21:39 [PATCH rdma-core] redhat/spec: can't build ibumad on 32-bit arm Jarod Wilson
     [not found] ` <20170109213944.31970-1-jarod-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-01-09 22:31   ` Jason Gunthorpe
     [not found]     ` <20170109223108.GA10850-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-01-10  3:27       ` Jarod Wilson
     [not found]         ` <0e01bfc8-333d-99dd-f7d1-024422923021-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-01-10 16:10           ` Jason Gunthorpe
     [not found]             ` <20170110161031.GB15493-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-01-12 12:32               ` Amrani, Ram
     [not found]                 ` <SN1PR07MB220756D06EA23CE46DEC11A2F8790-mikhvbZlbf8TSoR2DauN2+FPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-01-12 13:06                   ` Leon Romanovsky
     [not found]                     ` <20170112130640.GG20392-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
2017-01-12 13:15                       ` Amrani, Ram
     [not found]                         ` <SN1PR07MB2207AAD33488239E59339881F8790-mikhvbZlbf8TSoR2DauN2+FPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-01-12 17:14                           ` Jason Gunthorpe
2017-01-10 16:30       ` Hal Rosenstock
     [not found]         ` <a1b3f6cc-2de0-8a19-18dd-182f2cb7d3e1-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2017-01-10 17:36           ` Doug Ledford [this message]
     [not found]             ` <1484069764.2149.18.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-01-10 17:54               ` Jason Gunthorpe

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=1484069764.2149.18.camel@redhat.com \
    --to=dledford-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org \
    --cc=jarod-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox