IBM Ports Linux to S/390
smoon writes "The most expensive Linux platform available? IBM appears to be working on a port of Linux to S/390." First version is running on a VM. Second version will be running on 'Bare Metal' as they call it. Pretty cool if you happen to have a 390 sitting around somewhere ;)
The bad news is that it's strictly a server platform. I don't even know of a natively attached device that can serve as an X display; the 3270 display system is very much screen-oriented and block-structured, designed to have the user fill in a form and hit the ENTER key to have it all processed. They also don't handle async serial I/O worth a damn, necessitating a channel interrupt and transfer for every input keystroke. The upshot of this is that you'll run the system by telnetting into it, and if your IP configuration is hosed, you'll get to use some really horrendous tools to edit the necessary files.
--
Disinfect the GNU General Public Virus!
The Linux emulator makes sense. Check out their VM/ESA web page.
But on running linux as the base OS...
I remember interviewing with some OS/390 guys a while back... One of the interviewers worked in the OS messaging/IPC group. If I remember correctly, they had a very large number of people (around 100?) that did nothing but work on messaging and IPC.
The point is, OS/390 is a very very complex system for very very complex hardware. ja?
And the rumors expect to have linux ported to bare metal relatively soon? How many people would that have taken? How many years?
Here's a abbreviated list of S/390 G5/G6 Features:
Capacity Upgrade on Demand
Open Systems Adapter 2 (OSA-2)
OSA Express Express GbE
Dual cryptographic coprocessors
FICON channel 100MB/sec full-duplex
S/390 architecture
Clustered systems
Parallel Sysplex clustering technology
Sysplex Timer®
Integrated Coupling Migration Facility (ICMF)
Coupling Facility Control Code
Coupling links (HiPerLinks)
Internal Coupling (IC) Channel
Geographically Dispersed Parallel Sysplex
Integrated Cluster Bus (ICB)
Internal Coupling Facility (ICF)
Shared ICFs and CPs
Dynamic ICF Expansion
Transparent ICF Sparing
Dynamic CF Dispatching
Enhanced Parallel Sysplex Clock Functions
VM/ESA Virtual Parallel Sysplex
To the best of my knowledge, most of this stuff is outside the scope of the linux source tree. We're talking a large amount of work here to make linux take a moderate advantage of the underlying hardware. If they've done it, more power to them. But is just seems to be rumors to me.
And what about all the OS/390 software, is that being ported to linux also? How long will that take? Or will you only be able to run Domino on it? I guess that my point here is that there seems to be a large amount of good S/390 specific enterprise software out there. To run linux as the base OS would negate the advantages and capabilities of this software.
"You want to kiss the sky? Better learn how to kneel." - U2
"It was like trying to herd cats..." - Robert A. Heinlein
Sig:
Barbeque is a noun. Not a verb.
I find it intriguing that the rumours always fail to mention the Linux/390 site where the actual work is going on: Bigfoot-- Linux on a Mainframe. Why do the news reporters carry this as a rumour? Doesn't anyone fact check? And why does it say "IBM is doing this" ... only a small fraction of the people involved in this project are employed by IBM, its seems weird that IBM gets all the credit. Whazzup with that?
Actually, I've worked a lot on 390 series machines, and in fact this architecture is one of the best documented computer systems ever produced. The IBM 390 Principles of Operation describes every detail about the hardware you would ever want to know. There aren't any "secrets" that I'm aware of.
... it's actually pretty easy to do. Of course, in order to actually run your program on the bare iron, you'd need to bring down your mainframe and dedicate it to your program, which is sort of hard to justify ... and heck ... the whole reason VM was invented was because of this problem ... so why fight it?
... At the time, all VM/CMS had was a flat filesystem with 8.8 character filenames. Ouch!
...
... in both the IBM and Waterloo C compilers. The workaround for that was to make huge #include files that mapped all of the long function names into unreadable abbreviations.
... The 390 channel subsystem is based on a very high performance model, but it would have required a nearly complete rewrite of the device driver subsystems ...
... the 360/370/390 series has a 1M segment size instead of the more common 16M segment size. This means that a full 2G address space (the 390 series has a 31 bit address space, not a 32 bit address space), would require a 8192 byte segment table for each process. The largest piece of contiguous memory Linux could serve up at the time was 4096 bytes, so I was looking at a rework of the memory management routines ... and a rework of the paging routines for the differently-sized tables ...
...
Writing software that runs on the bare iron isn't a "mysterious" process
We tried AIX/ESA back when it first came out. It was EXTREMELY inefficient, not compatable with anything else in the world, and a general loser. It deserved to die.
Back in 1993, I sat down with the Linux source and looked into doing a port to our 3090.
The biggest problems I saw right away were:
1) Lack of a tree filesystem with long names
2) Lack of a suitable compiler. IBM's C compiler wasn't up to the job. I started to compile using the Waterloo C compiler, which was a better compiler, but I then ran into
3) 8 character symbol name limitations
4) Not to mention that all my development would have been done in an EBCDIC environment, and the GCC compiler, at the time, had ASCII specific logic, and defied porting. (In EBCDIC, the letters A-Z are *NOT* contiguous, and the numbers 0-9 come after the letters)
5) The output from the IBM compiler would have been in mainframe TXT format, which is basically 80 column punchcards. I didn't see an easy way to get from that to a unix style (a.out) format.
6) Device drivers
7) Paging differences
In fact, nearly the entire hardware interface layer was different enough that it would have had to be rewritten. Things like the filesystems looked like they could drop into place without any changes
but after a couple of weeks I came to the conclusion that this was much more then a "quick hack" project, and never pursued it. Always wish I had.