Slashdot Mirror
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 ;)
Seriously, though, if IBM produce an official, supported version for their medium or high-end hardware, Linux will start to be taken a WHOLE lot more seriously by the pointy-hair guys.
(After all, nobody ever got sacked for buying IBM, right...? :)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I think this is an great example of how Linux can be good for business. IBM can benefit by allowing customers to run Domino on mainframes, and the community benefits from the kernel source that IBM would release. Not only that, but IBM bolsters their image with the open source community.
As your PHB would say, "This is a win-win situation."
This sig is false.
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!
IBM supports TCP/IP on OS/390, and I have used a Linux system running X as an X-terminal to the "Unix System Services" facilities of such a machine.
Yes, IBM's 'native' networking doesn't support the usual cast of Unix remote devices, _but_ the newer IBM networking hardware _does_ support both SNA _and_ TCP/IP, making it easy to attach TCP/IP-enabled devices (terminals, printers, PCs, etc.) to the system. If they've moved any further ahead with Linux on S/390, I don't see any reason why you couldn't access the system from an xterm.
You certainly can do so now.
"values of beta will give rise to dom!"
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.
The mainframe model is that I/O is made really fast by using blocking to a massive degree. Interrupts == evil; blocking == good.
The UNIX model is more oriented towards streaming; this can be mapped onto blocks, but if the blocks are real tiny, this gets real inefficient.
This is already somewhat true on a UNIX when running applications across the network; a single keystroke may initiate a couple of packets of network traffic, thereby having a single byte update result in a couple hundred bytes having to cross the net. UNIX suffers somewhat when hit by interrupt-driven programs; MVS suffers a whole lot more.
The OS/390 hardware has been tuned to do block-oriented I/O, whether we consider disk drives, printers, or terminal controllers.
This may be a neat hack; I am quite unconvinced that it will lead to a commercially viable product, and in order for it to be of any importance, it has to be commercially viable.
Countervailing consideration; if some of the following components were provided some "deep hooks" to the kernel, they could both be coded to "bare iron," and thus be fast, and harness the "blockiness" of the hardware, but also allow integration work to take place in the Linux environment:
Linux could provide a way of gluing these things to (say) a web server, and providing an easy front end to customize, whilst letting the respective components take advantage of the hardware's strengths.
A web server is also likely to represent something that can run pretty effectively on MVS.
If you're not part of the solution, you're part of the precipitate.
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.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.