During Debconf 11, I got access to a
fast s390 machine, and I have started to work on a
Debian s390x port, the 64-bit version of the
s390 port. One of my goal was to
help the SPARC64 port, as some of the
issues are the same: both are 64-bit big-endian, don't support unaligned
access and behave differently between -fpic and -fPIC.
Why such a port?
When talking about 64-bit ports, we usually hear: "4GB is enough,
handling 64-bit takes more memory". This really sounds like "640K ought
to be enough for anybody". The s390 port is actually 31-bit from the
address point of view (one bit is reserved for address space extension
from 24 to 31 bits), so each process is limited to 2GB only. Nowadays
applications which need more than 2GB are not that uncommon, especially
on mainframes. Actually the 2GB limit already causes some problem in
Debian: in some cases it's not possible to build haskell
applications
or even C
applications
using GCC. On the other hand, we already require a 64-bit kernel on the
s390 port (only the userland is 32-bit), and applications are handling
more and more 64-bit or greater values (files offset, time counters,
uid, etc.).
What is the status?
Bootstrapping the architecture was not really easy (as for any other new
architectures), due to a huge amount of dependencies and
build-dependencies loops, as explained by
Wookey
during Debconf11. Now that this part is mostly done, an
autobuilder
has been started and currently more than
65% of the
packages are built. The s390x port is hosted on
debian-ports.org. Unfortunately it is not
yet deboostrapable, though that should happen in the next few days (only
a few packages are missing).
The main issues are currently packages which fail to build from source
due to
linker,
gcc-4.6
and curl
changes, or due to the
libjpeg
and
multiarch
transitions, and thus are not directly related to s390x. If your package
is in this case, it would be a good idea to fix it. Otherwise if it has
a lot of reverse dependencies and the bug is opened for a while, just
expect an NMU (as allowed by the 0-day NMU
policy).
Of course for a few packages s390x specific fixes are needed, some of
them are already in the BTS.
How can you help?
The list of bugs blocking the s390x port is available through the s390x
usertag,
fixing these bugs (a lot of them are general FTBFS) would help a lot.
Alternatively if you have access to an s390x machine you can take a look
at the packages failing to
build.
Update: Fixed the explanation about the 32th bit, thanks to Bastian
Blank for the comment.
