Thread: Linux for S/390 Patches
I have used the latest snapshot to create the following patches to provide
support for Linux on S/390. As you can see the additions are trivial. The
build went without a hitch. The regression tests went well with only geometry
failing due to a difference in the 13th decimal place; and in inet for reasons
I haven't explored fully.
Diffs:
======
--- ./src/include/port/linux.h 2000/11/16 21:48:46 1.1
+++ ./src/include/port/linux.h 2000/11/16 21:50:32
@@ -31,6 +31,11 @@
#elif defined(__ia64__)
typedef unsigned int slock_t;
#define HAS_TEST_AND_SET
+#elif defined(__s390__)
+typedef unsigned int slock_t;
+
+#define HAS_TEST_AND_SET
+
#endif
--- ./src/include/storage/s_lock.h 2000/11/16 21:50:55 1.1
+++ ./src/include/storage/s_lock.h 2000/11/16 21:53:20
@@ -126,10 +126,33 @@
return (int) _res;
}
#endif /* __arm__ */
+#if defined(__s390__)
+/*
+ * S/390 Linux
+ */
+#define TAS(lock) tas(lock)
+
+static inline int
+tas(volatile slock_t *lock)
+{
+ int _res;
+
+ __asm__ __volatile(" la 1,1\n"
+ " l 2,%2\n"
+ " slr 0,0\n"
+ " cs 0,1,0(2)\n"
+ " lr %1,0"
+ : "=m" (lock), "=d" (_res)
+ : "m" (lock)
+ : "0", "1", "2");
+
+ return (_res);
+}
+#endif /* __s390__ */
#if defined(__sparc__)
#define TAS(lock) tas(lock)
regress.out
===========
boolean .. ok
char .. ok
name .. ok
varchar .. ok
text .. ok
int2 .. ok
int4 .. ok
int8 .. ok
oid .. ok
float4 .. ok
float8 .. ok
numeric .. ok
strings .. ok
numerology .. ok
point .. ok
lseg .. ok
box .. ok
path .. ok
polygon .. ok
circle .. ok
date .. ok
time .. ok
timestamp .. ok
interval .. ok
abstime .. ok
reltime .. ok
tinterval .. ok
inet .. failed
comments .. ok
oidjoins .. ok
type_sanity .. ok
opr_sanity .. ok
geometry .. failed
horology .. ok
create_function_1 .. ok
create_type .. ok
create_table .. ok
create_function_2 .. ok
copy .. ok
constraints .. ok
triggers .. ok
create_misc .. ok
create_aggregate .. ok
create_operator .. ok
create_index .. ok
inherit .. ok
create_view .. ok
sanity_check .. ok
errors .. ok
select .. ok
select_into .. ok
select_distinct .. ok
select_distinct_on .. ok
select_implicit .. ok
select_having .. ok
subselect .. ok
union .. ok
case .. ok
join .. ok
aggregates .. ok
transactions .. ok
random .. ok
portals .. ok
arrays .. ok
btree_index .. ok
hash_index .. ok
misc .. ok
select_views .. ok
alter_table .. ok
portals_p2 .. ok
rules .. ok
foreign_key .. ok
limit .. ok
plpgsql .. ok
temp .. ok
regression.diffs
================
*** 54,63 ****
ten | cidr | broadcast | inet | broadcast
-----+--------------+------------------+------------------+------------------
| 192.168.1/24 | 192.168.1.255/24 | 192.168.1.226/24 | 192.168.1.255/24
! | 192.168.1/24 | 192.168.1.255/24 | 192.168.1.226 | 255.255.255.255
| 10/8 | 10.255.255.255/8 | 10.1.2.3/8 | 10.255.255.255/8
! | 10.0.0.0/32 | 255.255.255.255 | 10.1.2.3/8 | 10.255.255.255/8
! | 10.1.2.3/32 | 255.255.255.255 | 10.1.2.3 | 255.255.255.255
| 10.1.2/24 | 10.1.2.255/24 | 10.1.2.3/24 | 10.1.2.255/24
| 10.1/16 | 10.1.255.255/16 | 10.1.2.3/16 | 10.1.255.255/16
| 10/8 | 10.255.255.255/8 | 10.1.2.3/8 | 10.255.255.255/8
--- 54,63 ----
ten | cidr | broadcast | inet | broadcast
-----+--------------+------------------+------------------+------------------
| 192.168.1/24 | 192.168.1.255/24 | 192.168.1.226/24 | 192.168.1.255/24
! | 192.168.1/24 | 192.168.1.255/24 | 192.168.1.226 | 192.168.1.226
| 10/8 | 10.255.255.255/8 | 10.1.2.3/8 | 10.255.255.255/8
! | 10.0.0.0/32 | 10.0.0.0 | 10.1.2.3/8 | 10.255.255.255/8
! | 10.1.2.3/32 | 10.1.2.3 | 10.1.2.3 | 10.1.2.3
| 10.1.2/24 | 10.1.2.255/24 | 10.1.2.3/24 | 10.1.2.255/24
| 10.1/16 | 10.1.255.255/16 | 10.1.2.3/16 | 10.1.255.255/16
| 10/8 | 10.255.255.255/8 | 10.1.2.3/8 | 10.255.255.255/8
> I have used the latest snapshot to create the following patches to provide
> support for Linux on S/390. As you can see the additions are trivial. The
> build went without a hitch.
Great! I've applied the patches to my tree, and Bruce or I will
propagate them into CVS. I've also updated our list of supported
platforms :)
We list platforms by "OS" and "Processor". What would be the correct
entries for S/390? Presumably S/390 is the processor, but I'm not
familiar with how IBM does their labeling...
> The regression tests went well with only geometry
> failing due to a difference in the 13th decimal place; and in inet for reasons
> I haven't explored fully.
I'll guess that the inet failures are due to differences in bit-shifting
behavior when generating masks. Will you have time to look at it? You
are probably already familiar with the tree, but if not look in
src/backend/utils/adt/ for the inet support.
- Thomas
Thomas Lockhart writes:
> > I have used the latest snapshot to create the following patches to provide
> > support for Linux on S/390. As you can see the additions are trivial. The
^^^^^
> > build went without a hitch.
> We list platforms by "OS" and "Processor". What would be the correct
> entries for S/390? Presumably S/390 is the processor, but I'm not
> familiar with how IBM does their labeling...
About that list: We need to define a new primary key for it.
For example, "Linux 2.2.x" is wildly inaccurate. Red Hat probably works,
but maybe Caldera won't (true story). Maybe 2.2.16-suse-patches works but
2.2.14 won't (true story). The glibc version is probably equally (if not
more) important as the kernel version. So in matters Linux I think we
need to list the name and version of the distribution as it shows on the
box.
We also need to keep track of the compiler used. I've had situations
where gcc 2.8.1 didn't work on an otherwise normal Linux box. We've also
listed Solaris as supported although it was provably impossible to build
PostgreSQL with the native compiler.
I'd suggest a couple of concrete points to watch for before the upcoming
release:
1. Use the config.guess output as the primary way to index supported
platforms. This will make maintaining the build system much easier.
2. If there are several vendors that ship this system, also record the
name by which you'd ask for your system in the store.
3. If you didn't use the compiler (or other binutils) that came with your
system, record that.
4. Only list as supported actual systems from which you have actual
reports, no "3.x".
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> > I have used the latest snapshot to create the following patches to provide > > support for Linux on S/390. As you can see the additions are trivial. The > > build went without a hitch. > > Great! I've applied the patches to my tree, and Bruce or I will > propagate them into CVS. I've also updated our list of supported > platforms :) I will let you commit it, Thomas. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
config.guess comes back with s390-ibm-linux so s390 would be the choice for processor.
I'll attempt to track the differences down and get back to you.
-----Original Message-----
We list platforms by "OS" and "Processor". What would be the correct
entries for S/390? Presumably S/390 is the processor, but I'm not
familiar with how IBM does their labeling...
:
:
I'll guess that the inet failures are due to differences in bit-shifting
behavior when generating masks. Will you have time to look at it? You
are probably already familiar with the tree, but if not look in
src/backend/utils/adt/ for the inet support.