From: | Mark Salter <msalter(at)redhat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Raiskup <praiskup(at)redhat(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] Add support for TAS/S_UNLOCK for aarch64 |
Date: | 2013-06-04 18:05:55 |
Message-ID: | 1370369155.25297.184.camel@t520.redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2013-06-04 at 13:40 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Tue, Jun 4, 2013 at 11:48 AM, Pavel Raiskup <praiskup(at)redhat(dot)com> wrote:
> >> Oh, I see now it was already consulted here:
> >> http://www.postgresql.org/message-id/1368448758.23422.12.camel@t520.redhat.com
>
> > I think we should go ahead and commit this patch, or some variant of
> > it. Having a buildfarm machine would be good... but I don't think
> > that should be a prerequisite for this sort of support. We certainly
> > have spinlock support for other platforms for which we don't have
> > buildfarm machines.
>
> We got no response to the question of whether it couldn't be merged with
> the existing ARM32 code block. I'd prefer not to have essentially
> duplicate sections in s_lock.h if it's not necessary.
Of course it could be. I don't think it should be. Aarch64 is a
completely new architecture with faint resemblance to 32bit arm. I went
back and read the previous thread concerning the problems with builtin
gcc atomics with certain tool/hardware combinations. Would it be okay to
add a default implementation based on gcc builtins to be used if no
arch-specific definitions exist? If so, I could work up a patch for
review.
--Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Sean Chittenden | 2013-06-04 18:12:30 | Improved error message for CREATE EXTENSION patch... |
Previous Message | Tom Lane | 2013-06-04 17:40:27 | Re: [PATCH] Add support for TAS/S_UNLOCK for aarch64 |