Обсуждение: m32r tas() implementation

Hi PostgreSQL developers,

Kazuhiro Inaoka recently sent me a tas() implementation for the m32r
architecture [1]. It applies cleanly to 8.2.3 and seems otherwise
harmless. Do you consider applying it upstream?

Thank you,

Martin

[1] http://en.wikipedia.org/wiki/M32R

--
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org
diff -Nur postgresql-8.2/build-tree/postgresql-8.2.3/src/include/storage/s_lock.h
postgresql-8.2.new/build-tree/postgresql-8.2.3/src/include/storage/s_lock.h
--- postgresql-8.2.3/src/include/storage/s_lock.h    2006-06-08 00:24:45.000000000 +0200
+++ postgresql-8.2.3/src/include/storage/s_lock.h    2007-04-14 20:50:07.000000000 +0200
@@ -566,6 +566,15 @@
 #endif


+#if defined(__m32r__)
+#include <sys/tas.h>
+#define HAS_TEST_AND_SET
+
+typedef int slock_t;
+#define TAS(lock) tas(lock)
+
+#endif
+
 #endif    /* __GNUC__ */

Martin Pitt <martin@piware.de> writes:
> Kazuhiro Inaoka recently sent me a tas() implementation for the m32r
> architecture [1]. It applies cleanly to 8.2.3 and seems otherwise
> harmless. Do you consider applying it upstream?

The patch seems strongly dependent on an OS as well as a chip, since
<sys/tas.h> is hardly to be expected to exist everywhere.  Therefore,
it is at least short an #ifdef or so.  More generally I wonder if it's
not going at it backwards: if <sys/tas.h> exists, could we use it
regardless of CPU type?

            regards, tom lane

Yes, I'm expecting it to be applied to upstream.

Regards,
Kazuhiro Inaoka

Martin Pitt wrote:
> Hi PostgreSQL developers,
>
> Kazuhiro Inaoka recently sent me a tas() implementation for the m32r
> architecture [1]. It applies cleanly to 8.2.3 and seems otherwise
> harmless. Do you consider applying it upstream?
>
> Thank you,
>
> Martin
>
> [1] http://en.wikipedia.org/wiki/M32R
>
>

Kazuhiro Inaoka <inaoka.kazuhiro@renesas.com> writes:
> I'm porting only for Linux on m32r. I think m32r's tas() is depend on
> glibc's implementation.
> It's a system call now. So <sys/tas.h> should be used for Linux/m32r only.

Well, my point stands: sys/tas.h is not present on every Linux, so we
need at least another #ifdef here.  I'm not sure what it should be though.

            regards, tom lane

Tom Lane wrote:
> Kazuhiro Inaoka <inaoka.kazuhiro@renesas.com> writes:
> > I'm porting only for Linux on m32r. I think m32r's tas() is depend
> > on glibc's implementation.
> > It's a system call now. So <sys/tas.h> should be used for
> > Linux/m32r only.
>
> Well, my point stands: sys/tas.h is not present on every Linux, so we
> need at least another #ifdef here.  I'm not sure what it should be
> though.

But every Linux on m32r does have sys/tas.h.  It's among the glibc
header files for that port.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Your patch has been added to the PostgreSQL unapplied patches list at:

    http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------


Martin Pitt wrote:
-- Start of PGP signed section.
> Hi PostgreSQL developers,
>
> Kazuhiro Inaoka recently sent me a tas() implementation for the m32r
> architecture [1]. It applies cleanly to 8.2.3 and seems otherwise
> harmless. Do you consider applying it upstream?
>
> Thank you,
>
> Martin
>
> [1] http://en.wikipedia.org/wiki/M32R
>
> --
> Martin Pitt        http://www.piware.de
> Ubuntu Developer   http://www.ubuntu.com
> Debian Developer   http://www.debian.org

-- End of PGP section, PGP failed!

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Martin Pitt <martin@piware.de> writes:
> Kazuhiro Inaoka recently sent me a tas() implementation for the m32r
> architecture [1]. It applies cleanly to 8.2.3 and seems otherwise
> harmless. Do you consider applying it upstream?

Applied with addition of a configure probe for <sys/tas.h>.

            regards, tom lane