Linux for S/390, Part 2: Building the iron penguin
Linux takes to big iron within virtual machines
Jun 15, 2000
In the second article of this three-part series on the Linux port to IBM's System/390, Neale Ferguson describes how the idea of the Linux port to the S/390 came about and the technical details involved. (5,000 words)
By Neale Ferguson
n my first installment on Linux for S/390, I introduced the S/390 architecture and described the development of the VM/ESA operating system. With this as background, I'll now describe how the idea to port Linux to the S/390 came about and the technical details regarding the port.
Linux on S/390: Read the whole series!
Two ports in a storm
As Linux grew in popularity, the general population of computer programmers and administrators became Linux literate. This was also true in the S/390 world. There was even envy within the VM community; Linux was developing in the way VM's proponents had hoped their operating system would grow before IBM's Object Code Only (OCO) and Object Code Maintained (OCM) policies, both described in the first part of this series, crippled the community's ability to contribute. The skill base, the technology, and the application base within the Linux world are all highly attractive to any organization that wishes to keep growing.
As a long-time VMer, I could see that there were great synergies between the two operating systems. The initials VM refer to virtual machines running their own operating systems as guests. Sometimes ill-behaved guests are referred to as parasites, but Linux could be a very welcome guest, especially with source code available.
Therefore, it wasn't surprising when efforts to port Linux to yet another architecture were undertaken. There were two of these efforts: one done totally in the public eye, the other (by necessity, for the developers didn't want to scare the rest of their organization) done as a skunk-work project within IBM.
My first attempt to do a Linux on S/390 port was back in 1997, but I had neither the time nor the gcc-compiler skills to get very far. Fortunately, Linas Vesptas and David Pitts did (and still do!) have such skills (and more) and were able to build the infrastructure that enabled a port to happen.
I joined Linas in early 1999, bringing my access to significant S/390 resources (two-way SMPs, 725 MB memory, gigabytes of disk) to help the effort. We were soon joined by several others, including Rob Van Der Heij from the Netherlands and Peter Schulte-Stracke of Germany.
With Linas as our guiding light and designer of key architectural constructs, we were able to get together a kernel, nicknamed Bigfoot and based on the 2.2.10 level, that did the basics:
- Memory management
- Process control
- Primary I/O functions (device detection and limited driving)
- Rudimentary bottom-half handling
- RAM-disk handling
By September 1999, we were booting the kernel and had it to the stage of invoking the first user process.
Development was done primarily under VM/ESA and Hercules. The trace facilities of VM were indispensable. VM has many sophisticated trace capabilities that allow you to shoot bugs with I/O, virtual memory activities, program flow and control, register and storage modification, etc. It can produce bug reports interactively or generate a printout. Most of the time we would do things interactively, but the print facility, when coupled with the system map and a couple of simple scripts, produced extremely useful debugging aids.
It had been a long time since I as excited about programming as I was when I worked with Linas' early code. I used VM to trace the kernel and could see it had problems, so I downloaded the code, built a cross-compile environment, and started to hack away. What a great time I had, applying fixes and getting them running! Soon I was getting into the guts of the kernel and creating the code that brought S/390 and Linux together. Dynamic address translation and I/O support were just plain fun to implement.
Bigfoot was a totally public effort. Communications and diffs of the source code were published on Websites and on the LINUX-390 mailing list.
Amid our gradual progress, we began to hear rumors of a skunk-work project within IBM that was also porting Linux to S/390.
IBM is an interesting organization. It has more than its fair share of Nobel Prize winners, has some of the best minds in the industry, and a more than generous quota of people who are open and always willing to help. However, because of its size, it also has a bureaucracy of immense proportions and a goodly number of empire builders and ultraconservatives. This should not be a surprise as any organization this large is, in fact, a microcosm of society.
Thus, a project as politically sensitive and, perhaps, as radical as this had to proceed carefully -- it must have scared the living daylights out of some within the company. Therefore, a project involving a small group of dedicated developers was created and funded to develop the port.
The downside of this secrecy was that neither the lessons learned nor the information and code developed were able to be exchanged with the folks doing the other port. Numerous lessons learned during the development of the Bigfoot port were relearned in the IBM effort. This is a classic example of why true open source development can be so valuable.
There has been some justified feeling among the Bigfoot developers that their efforts were undervalued. If nothing else, however, I believe the public and published progress of the Bigfoot port helped force IBM's hand so that, on December 18, 1999, the company published the diffs to all its key components. The IBM team is now in constant public communication with the community through LINUX-390.
IBM is still getting the feel of how things are done in the open source world. In my personal opinion, it seems that Big Blue's management retains a sense of the "not invented here" syndrome. So far, the interaction between the community and the developers has been positive. Hopefully, these positives will promote the cause of open source and lead to a first-class port of Linux to S/390.
Getting it yourself
Interested? Why not check out the port yourself, even if it's only to see how things are implemented in a different environment? You can obtain a copy from the Marist College Linux for S/390 site (see the Resources section below the URL). Here, you'll get the instructions, the kernel, and a couple of filesystems.
Once you download all this, take some time to look at the code unique to the S/390 port. The next sections of this article will help you understand the technical ins and outs of the S/390 implementation.
New configuration Questions
The first step to configuring Linux on the S/390 happens with the Linux kernel configuration. Update your makefile with
ARCH:=s390 and begin the configuration with
make config or
make menuconfig and look for the parameter prompts in Table 1
Table 1. Linux on S/390 build parameters
|Select this option if you want to run the kernel on one of IBM's mainframes of the S/390 generation. You should have previously installed the s390-compiler released by IBM (based on gcc-2.95.1).|
|If you want to use the produced kernel to boot (or initial program load (IPL), as it's often called in S/390) directly from a device, you have to merge a boot sector specific to the device into the first bytes of the kernel. You will have to select the boot device on another question that pops up when you select |
|Select this option if you want to boot the image from a tape. |
|Select this option if you are running under VM/ESA and want to boot the image from the emulated card reader.|
|Select this option if you want to IPL the image from a real card reader. Maybe you still have one and want to try it. Not tested.|
|Enable this option if you want to access disks directly utilizing S/390's channel subsystem commands. This is necessary for running natively on a single image or an LPAR.|
|Selecting this option enables fast I/O for disks. That means that, if an I/O request is pending, the next I/O command is already issued at interrupt time. This option significantly speeds up I/O because S/390 doesn't schedule the bottom halves as often as Intel.|
|Enable this option to assure standard IBM labels on the disks. You must enable it if you are planning to access disks also attached to another IBM mainframe operating system (OS/390, VM/ESA, VSE/ESA).|
|ECKD devices are the devices most commonly used. You should enable this option unless you are certain that you have no ECKD devices.|
|CKD devices are currently unsupported.|
|FBA devices are currently unsupported.|
|Include IEEE floating point emulation code.|
|This option is used under VM only. With this flag enabled (|
Y), your S/390 can use a reserved minidisk under VM. The minidisk must be formatted and reserved under VM/CMS.
|This option is used under VM only. You can make the minidisk operation synchronous. |
|This option gives you the ability to make TCP/IP connections via virtual, parallel, or ESCON channels between Linux for S/390 machines and between Linux for S/390 and OS/390, VM, and/or VSE machines.|
|This is a VM-only network device driver that provides for very fast communication between VM userids. |
|The 3215 console driver is used to read and write to a 3215 line-mode console (a type of TTY). |
|This option enables console output on the first 3215 console in the system. It prints kernel errors and kernel warnings to the 3215 terminal, in addition to the normal output on the TTY device.|
|The hardware console (HWC) is an alternative terminal, usually required for a native Linux for S/390 installation, although it is also run under VM.|
|This option enables console output on the first hardware console in the system. It prints kernel errors and kernel warnings to the hardware console in addition to the normal output on the TTY device.|
So, let's look at those aspects within the S/390 architecture that these configuration questions influence.
S/390 architectural considerations
S/390 is a big-endian architecture that has:
- Sixteen 32-bit general-purpose registers
- Four floating-point registers in the older systems and sixteen in the newer ones, according to the IBM and IEEE formats
- Sixteen 32-bit control registers that control machine operation for address spaces, interrupt masks, etc.
- Sixteen 32-bit access registers that control the concurrent use of multiple address spaces
Program status word
The heart and soul of S/390 is the program status word (PSW). The PSW is the most important register on the machine; it is 64 bits long and serves multiple roles. The PSW has several advantages over a normal program counter in that you can change multiple settings (such as address translation and program counter) in a single instruction. The following table breaks down the PSW into its component bits:
Table 2. PSW component bits
|Reserved. Must be 0, or a specification exception occurs.|
|Program Event Recording (PER). A value of 1 indicates that PER is enabled. PER is used to facilitate debugging -- single stepping, for example.|
|Reserved. Must be 0.|
|Dynamic address translation (DAT). A value of 1 means that DAT is on.|
|Input/output interrupt mask.|
|External interrupt mask. Used primarily for interprocessor signaling and clock interrupts.|
|PSW key. Used for a complex-memory protection mechanism not used under Linux.|
|Machine check mask. A value of one means that machine check interrupts are enabled.|
|Wait state. Set this to 1 to stop the processor except for interrupts and give time to other LPARs. |
|Problem state. If set to 1, certain instructions are disabled. All Linux user programs run with this bit enabled.|
|Address space control. The potential meanings for values in these bits are as follows:|
- 00 -- Primary space mode, with DAT on. The Linux kernel currently runs in this mode; control register 1 (CR1) is affiliated with this mode and points to the primary segment table origin, etc.
- 01 -- Access register mode. This mode is used in functions to copy data between kernel and user space.
- 10 -- Secondary space mode, not normally used Linux except to copy data between the kernel and user spaces. Control register 7 (CR7) is affiliated with this mode. Normally CR13 is mapped to CR7, allowing the copying of data between the kernel and user space. We do this as follows: we set AR2 to 0 to designate that its affiliated GPR (GPR2) should point to primary (kernel space). We set AR4 to 1 to designate that affiliated GPR (GPR4) should point to secondary (home or user space) and then essentially do a
memcopy(gpr2,gpr4,size) to copy data between the address spaces. The reason we use home for the kernel and don't keep the secondary space free is that the code will not normally run in secondary space.
- 11 -- Home space mode. All user programs run in this mode. It is affiliated with CR13.
|Condition codes (CC).|
|Fixed point overflow mask. This bit is normally set to 0; if it is sent to 1, floating point unit (FPU) exceptions for this event occur.|
|Decimal overflow mask. This bit is normally set to 0; if it is sent to 1, floating point unit (FPU) exceptions for this event occur.|
|Exponent underflow mask. This bit is normally set to 0; if it is sent to 1, floating point unit (FPU) exceptions for this event occur.|
|Significance mask. This bit is normally set to 0; if it is sent to 1, floating point unit (FPU) exceptions for this event occur.|
|Reserved. Must be 0.|
|If this bit is set to 1, 31-bit addressing mode should be used; if it is set to 0, 24-bit addressing mode should be used for backward compatibility. Linux always runs with this bit set to 1.|
|Instruction address (program counter).|
Interrupts are implemented by storing the current PSW and loading a new PSW. This is similar in concept to a vector interrupt table. There are five main types of interrupts defined for S/390. Each type has several different classes that qualify the type of interrupt and are stored in a specified low-core area upon interrupt. These types are:
- External: External events such as timers or signals from other CPUs. The event type is stored as the qualifier.
- Supervisor call: Program-controlled signal to operating system. A code 0x00-0xff is stored as the qualifier.
- Program check: Invalid instructions, page translation exceptions, access violations. The type of program fault is stored as the qualifier.
- Machine check: Hardware component warning or failure notification. The type of failure is stored as the qualifier.
- I/O: Input/output device status changes. The identifier of the device causing the interrupt is stored as the qualifier.
On VM, you can display these PSWs for a virtual machine or you can use the hardware-management console if running on the bare iron or within an LPAR:
Figure 1. PSW display
This per-CPU memory area is too intimately tied to the processor not to mention. It exists between the real addresses 0 and 4096 (the first page) on the processor and is exchanged with a page in absolute storage by the set prefix instruction in Linux's startup. There is an instance of this page for each real or virtual processor attached to the virtual machine. The prefix register holds the address of the prefix page. Bytes 0 through 512 (200 hex) are used by the processor itself for holding such information as exception indications and entry points for exceptions.
Linux uses bytes after 0xc00 hex for per-processor globals. The closest thing to this on traditional architectures is the interrupt vector table. This simplifies some of the kernel coding. However, it means that we now cannot catch stray null pointers in the kernel without hardcoded checks. You can find more information in Barrow, 2000 in the Linux source tree -- see Resources for the path.
First, some quick definitions from the ESA/390 Principles of Operations (ESAPOP) document by IBM:
For purposes of addressing main storage, three basic types of addresses are recognized: absolute, real, and virtual. The addresses are distinguished on the basis of the transformations that are applied to the address during a storage access. Address translation converts virtual to real, and prefixing converts real to absolute. In addition to the three basic address types, additional types are defined which are treated as one or another of the three basic types, depending on the instruction and the current mode.
- An absolute address is the address assigned to a main storage location. An absolute address is used for a storage access without any transformations performed on it.
- A real address identifies a location in real storage. When a real address is used for an access to main storage, it is converted, by means of prefixing, to an absolute address.
- A virtual address identifies a location in virtual storage. When a virtual address is used for an access to main storage, it is translated by means of dynamic address translation to a real address, which is then further converted by prefixing to an absolute address.
- A primary virtual address is a virtual address that is to be translated by means of the primary segment-table designation. Logical addresses are treated as primary virtual addresses when in the primary-space mode. Instruction addresses are treated as primary virtual addresses when in the primary-space mode, secondary-space mode, or access-register mode.
- A secondary virtual address is a virtual address that is to be translated by means of the secondary segment-table designation. Logical addresses are treated as secondary virtual addresses when in the secondary-space mode.
- An AR (access register) specified virtual address is a virtual address that is to be translated by means of an AR-specified segment-table designation. Logical addresses are treated as AR-specified addresses when in the access-register mode. Access registers allow you to use 16 2 GB address spaces concurrently.
- A home virtual address is a virtual address that is to be translated by means of the home segment-table designation. Logical addresses and instruction addresses are treated as home virtual addresses when in the home space mode.
Dynamic address translation
The process of translating a virtual address to a real address consists of a lookup using two tables: a segment table and a page table. These tables reside in real or absolute storage.
Figure 2. Dynamic address translation
Figure 2 presents a simplified overview of dynamic address translation as it's performed in S/390. Basically:
- A 31-bit virtual address is broken down into a segment index (SX), page index (PX), and byte index (BX).
- Depending on the addressing mode, a control register points to a segment table origin.
- Each 32-bit entry within the segment table represents 1 MB of storage and indicates whether there is a valid page table available to map real storage.
- The SX portion of the virtual address is used to index into the segment table.
- The indexed entry points to a page table.
- Each entry within the page table represents 4,096 bytes of storage and indicates whether the page actually exists in real storage.
- The PX portion of the virtual address is used to index into the page table.
- The indexed entry points to the beginning of a page in storage (a page frame address).
- The BX portion of the virtual address is used as the offset within this page frame. The result is the real address.
There is one more step that S/390 uses: transforming the real address into an absolute address by adding the contents of the prefix register. This mechanism allows the implementation of SMP in the architecture by providing each processor with its own page 0.
There is also a hardware shortcut available called the translate lookaside buffer (TLB). A lookup of this table uses the SX and PX indexes to index a table of recently accessed page frames. This search occurs in parallel with the normal translation process. If an address is found in the TLB, then the normal process is terminated and the page frame address found in the TLB is used to form the real address.
In contrast to most other hardware architectures, ESA/390 has defined a unified I/O access method. This relieves the device drivers of some responsibilities, as they don't have to deal with differing bus types, polling versus interrupt processing, shared versus nonshared interrupt processing, DMA versus port I/O (PIO), and other hardware features as much as they would on other systems. However, this implies either that every single device driver needs to implement the hardware I/O attachment functionality itself or that the operating system must provide for a unified method to access the hardware, thus providing all the functionality that every single device driver would otherwise have to provide. In order to build common device support for ESA/390 I/O interfaces, a functional layer was introduced that provides generic I/O access methods to the hardware.
The ESA/390 hardware platform knows about a huge variety of peripheral attachments, like disk devices (also known as DASD), tapes, and communication controllers. All these devices can be accessed by a well-defined access method and the present I/O completion in a unified way: I/O interruptions. Every single device is uniquely identified to the system by a so-called subchannel, where the ESA/390 architecture allows for 65,536 devices to be attached. (See the reference to Lung in Resources.)
In order not to introduce a new I/O concept to the common Linux code, Linux for S/390 preserves the IRQ concept and semantically maps the ESA/390 subchannels to Linux as IRQs. This allows Linux for S/390 to support up to 65,536 different IRQs, representing a single device each.
There are several new devices defined for S/390:
/dev/dasdxn -- Disks that use the extended count key data (ECKD) geometry, such as 3390. Under VM, these can be subsets of a full device that Linux sees as a real (although smaller than normal) device. These minidisks can live anywhere on a real disk and can be moved from real device to real device.
/dev/mndx -- VM minidisks of any geometry. The minidisks may be ECKD, count key data (CKD), or fixed-block architecture (FBA) geometries. They appear to Linux as pure fixed-block devices. As with other VM minidisks, these can live anywhere and can, in fact, be VM RAM disks.
/dev/ctcn -- Channel-to-channel adapter, which is a device used to connect CPUs. Under VM, these can be virtual (memory-to-memory constructs) and can be used to connect virtual machines.
/dev/osan -- The open systems adapter, which will eventually provide a Fast Ethernet, Token Ring, FDDI, or ATM interface to a network. Currently, only Ethernet and Token Ring are supported.
/dev/iucv -- A VM-only method of connecting virtual machines. This is basically a storage-to-storage transfer mechanism that transfers data up to 500 MBs. (You read it right: bytes per second, not bits!)
Support for an emulated dumb TTY and the S/390 hardware console for booting Linux is provided.
Until recently, IBM had its own floating-point hardware implementation that predated IEEE. It had advantages over IEEE, but also had disadvantages, the most obvious and important of which is compatibility! Not all of the S/390 hardware has the IEEE support, but the Linux for S/390 code incorporates software emulation (just like 80387 emulation on the Intel platform).
Control Registers are used to modify the operation of the S/390. Linux for S/390 uses the following control register settings.
Control register 0
Figure 3. Control register 0
Some notes on Figure 3:
- This bit is set for VM configurations only. IUCV is used as a TCP/IP network driver.
- Floating-point registers 0, 2, 4, and 6, are available on all ESA/390 models. The remaining 12 floating-point registers (1, 3, 5, and 7 through 15) are referred to as the additional floating-point (AFP) registers. The AFP registers are installed in the CPU when the basic floating-point extensions facility is installed and can be used only if bit 13 of control register 0, the AFP-register control bit, is set to 1. Attempting to use an AFP register when the basic floating-point-extensions facility is not installed results in a specification exception. Attempting to use an AFP register when the basic floating-point extensions facility is installed and the AFP-register control bit is 0 results in an AFP-register data exception (DXC 1).
Control register 1
This register points to the segment table for the primary address space and defines the length of the table.
Figure 4. Control register 1
Control registers 2 through 5
These registers are used for linkage-stack and address-space operations. In Linux for S/390, these registers are saved and restored for each task but never set.
Control register 6
I/O devices can have an interrupt subclass mask associated with them. This facilitates the selective enabling or disabling of interrupts from a class of I/O devices. For example, low-speed disks could all belong to a single class.
Figure 5. Control registers 6
Control register 7
Control register 7 holds the address of the segment table for the secondary address space.
Figure 6. Control registers 7
Control register 8
This register is used for monitor calls (MC). In Linux for S/390, this register is saved and restored for each task but never set.
Control registers 9 through 11
These registers are used for program event recording (PER). In Linux for S/390, these registers are saved and restored for each task but never set.
Control register 12
This register is used for tracing. The register is saved and restored for each task but never set.
Control register 13
This register points to the home space segment table.
Figure 7. Control registers 13
Control register 14
This register is used to control some machine check conditions.
Figure 8. Control registers 14
Control register 15
This register is used for linkage-stack operations. In Linux for S/390, this register is saved and restored for each task but never set.
On Intel, it is quite easy to recognize a kernel address as being one greater than user space high memory (in this case 0xC0000000). Addresses lower than this are the ones in the current running program on this processor (if we're discussing an SMP box). If you're using the virtual machine (VM) as a debugger, it is quite difficult to know which user process is running, as the address space you are looking at could be from any process in the run queue. Thankfully, address spaces don't normally overlap and you can recognize the code by cross-referencing with a dump made by
objdump (more about this later).
Figure 9. Intel's address spaces
The limitation of Intel's addressing technique is that the Linux kernel uses a very simple real address for the virtual addressing technique:
Real address = Virtual address - user space high memory
This means that on Intel the Linux kernel can typically only address 1 GB:
High memory = 0xFFFFFFFF - 0xC0000000 = 1 GB
1 GB is thus all the RAM that these machines can typically use. They can lower user high memory to 2 GB or less, and thus be able to use 2 GB of RAM. However, this shrinks the maximum size of user space from 3 GB to 2 GB: they have a no-win limit of 4 GB unless they go to a 64-bit architecture.
S/390's limitations and strengths make it slightly different. For backward compatibility, only 31 bits (2 GB) of our 32-bit addresses are used. However, we use entirely separate address spaces for the user and the kernel. This means we can support 2 GB of nonextended RAM, and more with the extended memory management swap device and 64-bit addressing when it comes along.
Figure 10. S/390's address spaces
Using System/390's address-space support allows operations like copying back and forth between user space and kernel space to be implemented with just a few instructions.
Using VM/ESA's virtual machines, you can facilitate horizontal growth by simply defining additional virtual machines running Linux.
Debugging under VM/ESA
In addition to such debugging facilities in Linux as
strace, there is a vast set of tools available to the kernel hacker under VM/ESA. The most useful of these is the
TRACE command. With this command, VM will trap various events or instructions within a virtual machine. You are able to step through instructions and watch for changes in the contents of storage or registers, restricting your activity to one virtual CPU out of many. The following is an overview of what's available, with examples:
syscalls and show me the registers and the contents addressed by register 1 when the trap is sprung. These are implemented by the supervisor call (SVC) instruction. On interrupt, the user address space is designated as the secondary address space:
Figure 11. Tracing syscalls
Trace all supervisor calls. Don't stop. When trap springs, issue a command to display 16 bytes of storage in the secondary address space pointed to by register 1, as well as the other general registers.
-> 40043E2E" SVC
In the S/390 implementation, the code
X'AE' equates to the
rt_sigaction system call.
The storage addressed by register 1 is displayed as well as the contents of the registers:
7FFFF450 00000001 00000000 00000000 00000000 06 L0565F450
GPR 0 = 7FFFF508 7FFFF450 00000015 7FFFF3C0
GPR 4 = 7FFFF450 00000008 00424FC0 7FFFF8F8
GPR 8 = 00401B9C 7FFFF600 7FFFFE88 7FFFF570
GPR 12 = C0114AE0 C0043D84 C0043DBC 7FFFF340
-> 400AC174" SVC 0A39 -> 0001909A' CC 0
V400AC174 0A39A748 F0011524 A7B40003 07FE0D10 06 L07D96174
GPR 0 = 7FFFF508 400AC174 00000190 00000190
GPR 4 = 7FFFF450 00000008 00424FC0 7FFFF8F8
GPR 8 = 0040233C 7FFFF8F8 7FFFFE88 7FFFF690
GPR 12 = C0114AE0 80424FC8 80425240 7FFFF690
-> 40043FD6" SVC 0AAF -> 0001909A' CC 0
V7FFFF588 00390000 00000000 00000000 00000000 06 L0565F588
GPR 0 = 7FFFF520 7FFFF588 00000000 7FFFF588
GPR 4 = 7FFFF608 00000008 00424FC0 7FFFF8F8
GPR 8 = 00000000 4003847C 7FFFFE88 7FFFF520
GPR 12 = C0114AE0 C0043F68 C0043FA2 7FFFF498
Trace timer pops by tracing external interruptions of type 0x1004, which signify the popping of the S/390 clock comparator:
*** 0001B2A0' EXT 1004 -> 000198B2'
*** 0001B2A0' EXT 1004 -> 000198B2'
*** 0001B2A0' EXT 1004 -> 000198B2'
Trace the first
X'40' bytes of instructions and any changes to the contents of registers in the I/O top-half processor.
D PSW I/O
I/O 000C 38 OLD 070C0000 800703D0 78 NEW 04080000 800197BC
TRACE I R 197BC.40 RUN
TRACE G R 197BC.40 RUN
-> 000197BC' ST 50F00C00 >> 00000C00 CC 0
000197C0' TM 91010039 00000039 CC 0
000197C4' BRC A7840004 -> 000197CC' CC 0
-> 000197CC' AHI A7FAFF08 CC 2 G15=056318E8
000197D0' SRL 88F00003 00000003 CC 2 G15=00AC631D
000197D4' SLL 89F00003 00000003 CC 2 G15=056318E8
000197D8' STM 900EF068 >> 05631950 CC 2
000197DC' ST 5020F0E8 >> 056319D0 CC 2
000197E0' MVC D203F0A40C00 >> 0563198C 00000C00 CC 2
000197E6' STAM 9B0FF0A8 >> 05631990 CC 2
000197EA' MVC D207F0600038 >> 05631948 00000038 CC 2
000197F0' XC D706F000F000 >> 056318E8 056318E8 CC 0
000197F6' MVI 9238F0EF >> 056319D7 CC 0
000197FA' SLR 1F00 CC 2 G00=00000000
Trace I/O operations to a network driver (using network devices
TR I/O 440 INT CCW RUN
TR I/O 441 INT CCW RUN
-> 0002059A' SSCH B2334000 0034D344 CC 0 SCH 0001 DEV 0441
CPA 07EFDCE0 PARM 00000000 KEY 0 FPI C0 LPM 80
VDEV 0441 CCW E3600000 00000000 STS 0C
CCW 0160005C 05820000 STS 00 DATA 005C005A08000000 ... STS 0C
CCW 03200000 00000000 STS 0C
*** 00078A56' I/O DEV 0441 -> 000197BC' SCH 0001 PARM 00000000
*** 0001B2A0' I/O DEV 0440 -> 000197BC' SCH 0000 PARM 00000000
-> 0002059A' SSCH B2334000 0034D154 CC 0 SCH 0000 DEV 0440
CPA 07EFDC70 PARM 00000000 KEY 0 FPI C0 LPM 80
IBM has provided the open source community with a robust implementation of Linux that exploits the strengths of the S/390 architecture. In addition, the tools and facilities provided by VM/ESA enable a developer to perform complex and exhaustive testing in what appears to be his or her own S/390 processor.
In the final installment in this series, of articles I will be looking at Linux for the S/390 in action. I will attempt to address such questions as: What can you run on it? What does it look like? How does it behave?
||About the author
Neale Ferguson is a longtime IBM S/390 system administrator with over nineteen years of experience with VM/ESA. He worked on the non-IBM port of Linux to S/390 and jumped to the IBM-sponsored effort as soon as it was released. Formerly with TAB Limited in Sydney, Australia, he currently works as a consultant at Computer Associates in Reston, Va.
Copyright © 1998-2002 LinuxWorld.com, an IDG Communications company.