Horton

Thread

Commits

  1. Add support for Motorola 88K to s_lock.h.

  2. Use out-of-line M68K spinlock code for OpenBSD as well as NetBSD.

  1. [PATCH] Porting small OpenBSD changes.

    David CARLIER <devnexen@gmail.com> — 2017-11-19T09:00:36Z

    Hi,

Compilation pass, make check passes.

Motivations :

- Reducing OpenBSD postfgresql maintainer internal changes bookeeping if
those small changes make sense for the PostgreSQL developers.

Hope it is good.

Thanks in advance.

Kind regards.

  2. Re: [PATCH] Porting small OpenBSD changes.

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-11-20T18:49:58Z

    David CARLIER <devnexen@gmail.com> writes:
> - Reducing OpenBSD postfgresql maintainer internal changes bookeeping if
> those small changes make sense for the PostgreSQL developers.

Hm.  The s_lock.c change is surely fine if OpenBSD maintainers say it is.

Not sure about adding Motorola 88K support to s_lock.h ... is anybody
really still interested in that platform?  OTOH, we still have M68K
and VAX stanzas in that file, so I suppose it's silly to complain
about 88K.  A bigger issue is that I wonder whether that code has
ever been tested: it does not look to me like the __asm__ call is
even syntactically correct.  There should be colons in it.

			regards, tom lane

  3. Re: [PATCH] Porting small OpenBSD changes.

    David CARLIER <devnexen@gmail.com> — 2017-11-20T18:57:47Z

    On 20 November 2017 at 18:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> David CARLIER <devnexen@gmail.com> writes:
> > - Reducing OpenBSD postfgresql maintainer internal changes bookeeping if
> > those small changes make sense for the PostgreSQL developers.
>
> Hm.  The s_lock.c change is surely fine if OpenBSD maintainers say it is.
>
> Not sure about adding Motorola 88K support to s_lock.h ... is anybody
> really still interested in that platform?


Yes there is :-)


> OTOH, we still have M68K
> and VAX stanzas in that file, so I suppose it's silly to complain
> about 88K.  A bigger issue is that I wonder whether that code has
> ever been tested: it does not look to me like the __asm__ call is
> even syntactically correct.  There should be colons in it.
>
>
True :-) corrected. Thanks.


>                         regards, tom lane
>

  4. Re: [PATCH] Porting small OpenBSD changes.

    David Fetter <david@fetter.org> — 2017-11-20T19:16:40Z

    On Mon, Nov 20, 2017 at 06:57:47PM +0000, David CARLIER wrote:
> On 20 November 2017 at 18:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> > David CARLIER <devnexen@gmail.com> writes:
> > > - Reducing OpenBSD postfgresql maintainer internal changes bookeeping if
> > > those small changes make sense for the PostgreSQL developers.
> >
> > Hm.  The s_lock.c change is surely fine if OpenBSD maintainers say it is.
> >
> > Not sure about adding Motorola 88K support to s_lock.h ... is anybody
> > really still interested in that platform?
> 
> 
> Yes there is :-)

Any chance of a buildfarm http://www.pgbuildfarm.org/ member or two
with this architecture?

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

  5. Re: [PATCH] Porting small OpenBSD changes.

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-11-20T22:24:03Z

    David CARLIER <devnexen@gmail.com> writes:
> On 20 November 2017 at 18:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> OTOH, we still have M68K
>> and VAX stanzas in that file, so I suppose it's silly to complain
>> about 88K.  A bigger issue is that I wonder whether that code has
>> ever been tested: it does not look to me like the __asm__ call is
>> even syntactically correct.  There should be colons in it.

> True :-) corrected. Thanks.

I still dare to doubt whether you've tested this, because AFAICS
the operand numbering is wrong.  The "r"(lock) operand is number 3
given these operand declarations, not number 2.

Our practice elsewhere in s_lock.h is to use a "+" constraint instead of
duplicated operands, and I think that's better style because it avoids any
question of whether you're supposed to count duplicated operands.

Also, per the comment near s_lock.h line 115, it's important to specify
"+m"(*lock) as an output operand so that gcc knows that the asm
clobbers *lock.  It's possible that "memory" makes that redundant,
but I'd just as soon maintain consistency with the well-tested
other parts of the file.

So I propose the attached patch instead.  It would still be a good idea
to actually test this ;-)

			regards, tom lane

  6. Re: [PATCH] Porting small OpenBSD changes.

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-11-20T22:36:15Z

    I wrote:
> I still dare to doubt whether you've tested this, because AFAICS
> the operand numbering is wrong.  The "r"(lock) operand is number 3
> given these operand declarations, not number 2.

Oh, my apologies, scratch that.  Evidently I put in the "+m"(*lock)
operand and confused myself about what was what.

I still think the form I proposed is better style though.

			regards, tom lane

  7. Re: [PATCH] Porting small OpenBSD changes.

    David CARLIER <devnexen@gmail.com> — 2017-11-20T22:38:37Z

    I m not against, I would go with your final version too. Thanks !

On 20 November 2017 at 22:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I wrote:
> > I still dare to doubt whether you've tested this, because AFAICS
> > the operand numbering is wrong.  The "r"(lock) operand is number 3
> > given these operand declarations, not number 2.
>
> Oh, my apologies, scratch that.  Evidently I put in the "+m"(*lock)
> operand and confused myself about what was what.
>
> I still think the form I proposed is better style though.
>
>                         regards, tom lane
>

  8. Re: [PATCH] Porting small OpenBSD changes.

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-11-20T23:05:54Z

    David CARLIER <devnexen@gmail.com> writes:
> I m not against, I would go with your final version too. Thanks !

Pushed to all supported branches.

			regards, tom lane