Linux on the IBM ESA/390 Mainframe Architecture

News Flash! Bigfoot is not alone! There are now two ports of the Linux kernel to the IBM S/390. The first port is documented in greater detail below. The second port was developed by IBM engineers living in a cave. Because they had no access to the outside world, this port is completely incompatible. However, market realities are such that the IBM effort is currently the defacto leader. That project is staffed by a number of paid, full-time developers, whereas this project was staffed by a small number of unpaid volunteers. That code is the focus of intensive ongoing development, test and deployment, while this project is in hibernation, with no active development going on at this time.

This may still change. There are still a few sticky points with the s390 port that probably aren't important, but could make thing ugly if not eventually resolved. These are:

• Assignment. The s390 tool chain (compiler, assembler, C library) has not been assigned to the FSF for inclusion into the mainstream distribution. Assignment requires some legal paperwork to be performed; for various internal reasons, IBM may find it difficult to do the assignment. However, if it is not done, then maintaining the separate s390 patch tree can become tedious, leading to all sorts of inconveniences.

• Vendor Neutral Forum. Currently, the s390 development efforts are controlled de-facto by IBM. This makes it difficult for the 'mainframe clone' vendors: Hitachi and Fujitsu, to participate. Overall, the project is weakened by this, and it would benefit considerably from a more open, more inclusive style. Both other members of the at-large community, as well as representatives from other vendors should get a more transparent process.

• Proprietary Hardware. Many aspects of the operation of mainframes are governed by proprietary, confidential documentation. For example, the interface to OSA (the network adapter) is secret. IBM has provided a binary (Object-Code-Only) driver for this interface, in clear violation of the Linux Kernel GPL. So far, no one is complaining, since a binary-only network interface is better than no interface at all, but clearly, this cannot stand as is for long.

• Pricing. Currently, IBM licenses its OS software on a month-by-month basis, and the rental cost is based on the number of installed CPU's (MIPS) that a customer has. This has a strong, negative impact on Linux or any non-IBM OS: Lets say half of a mainframe runs a traditional IBM operating system, and the other half runs Linux/390. Under current contracts, customers would get billed at full-price, and not at the half-price one would expect. This is a serious issue: the cost of hardware is a small (10%-20%) part of the total cost of running a mainframe. The cost of the raw hardware is comparable to (or even less than) that from Sun or HP or SGI; its the cost of the software that makes mainframes expensive. This issue is further clouded by 'bundling': an OS pricing model where the cost of the hardware is thrown in 'for free', which could mortally wound the mainframe clone makers. If instead, software pricing was 'fair', then Linux/390 could be a serious threat to the high-end systems from Sun, HP and SGI.

• Older Hardware. The s390 port only runs on the newest generation of hardware. Very few sites have this hardware. The i370 port supports an older instruction set, and thus opens the door to owners of older systems.

• Large GOT. The current s390 compiler doesn't support a large GOT. A large GOT is needed to compile programs with a large number of symbols in them. Supposedly, this is being fixed ...

• Assembly Style. The i370 assembler supports an assembly style that is more familiar to traditional mainframe coders. The s390 assembler supports a syntax that resembles Intel/x86 style. I think that the s390 design choice was a mistake, which is why they have large-GOT problems, etc.

If the above sounds like a critique of the s390 port, keep in mind that the s390 port is currently more technically advanced, and is the subject of active use and ongoing development. Note that the i370 port is stagnant.

June 2024 update!

August 2024 update!

• Incorrect offsets in the literal table for =A address constants (literals).
• Failed output of =XL8 literals on 32-bit arches
• Failed output of =E floating point and =D double precision constants.

Who the heck needs an MVS-work-alike in 2024? Appearently, PDOS (Public Domain Operating System) and PDPCLIB (Public Domain Project C Library) do. This version of the assembler, plus the i370 compiler are central to that effort.

September 2024 update!

The Bigfoot Port (aka i370)

• A Linux-ELF back end to the gcc/egcs compiler has been developed and is stable enough to compile medium/large systems such as the Linux kernel or glibc. It should be considered beta, in that most known bugs have been fixed although we still find new bugs from time to time. It includes all of Dave Pitts patches (described below) and fixes a large variety of code-generation bugs. Patches to egcs-1.1.2 are at http://linas.org/linux/i370/. Alternately, an almost (but not quite) up-to-date version of this compiler is also available via the gcc CVS tree. Visit http://egcs.cygnus.com/ and follow the CVS instructions to get access to the latest code.

  Notes:

  • There may be bugs with the 64-bit integer math and/or the produced code may be very inefficient.
  • There may be bugs with the floating-point math.
  • Support for relocatable objects is experimental. Relocatable position independent code (PIC) is needed for shared library and dynamic linking support. The PIC code is available only for the elf back end, not the MVS/USS backend.

• David Pitts has been maintaining an HLASM-compatible version of gcc for the MVS/Open Edition/C Environment. Among other things, it has ASCII-EBCDIC fixes to allow it to build & run on MVS. This, as well as pre-built binaries are available at David Pitts' GCC/EGCS Compiler Page.

• A Linux-ELF assembler has been developed. It is a port of the gnu binutils-2.9.5 assembler and object file format tools, including the assembler gas, the loader ld, dis-assembler objdumop etc. Download it here. The assembler is *not* HLASM compatible; it accepts the SVR4-style ELF assembly generated by the egcs/gcc compiler described above. The binaries it produces are ELF binaries, and not ESD/XSD binaries. It should be possible to run these binaries on any mainframe OS, provided you had an ELF loader.

  The assembler includes support for all of the privileged kernel mode instructions. It does not support the vector instructions.

  • ESA/390 Principles of Operation (alt location) for the machine architecture, including the full instruction set, addressing modes, interrupts, etc.
  • The ESA/390 Architecture Bookshelf has the 390 hardware docs
  • The ESA/390 Bookshelf points at a large set of online 390 docs.
  • Version 4.1 of the ELF (SysV) ABI in (Postscript) or (Acrobat PDF).
  • Melinda Varian's VM Past Present and Future

• A port of the Linux kernel has been started. It compiles. It runs, sort-of. Currently, due to a bug in the i370-glibc and/or the i370-gcc compiler, it crashes before the command line prompt is printed. Currently, keyboard input is not supported. Currently, there are no disk drivers. There are no network card drivers. It should be possible to port disk and network drivers over from the s390 project without too much trouble.
  • Sources are here.
  • Pre-built, bootable Linux kernel, SALIPL boot loader. Now you can try this in the comfort of your own home!
  • Boot Instructions, including a detailed explanation of how to configure your VM minidisk for boot.
  • 3990/9390 Reference defines the interfaces to the disk drives
  • PRSM Planning Guide provides insight into what an LPAR is, and how to set one up.

• A port of glibc has been started. System calls work. Signals don't. Patch are here.

• A very very brief intro to Getting Started Hacking on Linux/390.

• Join the mailing list: send mail to listserv@vm.marist.edu saying subscribe linux-vm Your Name to join the mailing list. Or browse the mailing list archives.

Why do this?

Postscript