Why Port Linux to the Mainframe?

Stunt

OK, its a stunt. Bragging rights. Isn't that why anybody does anything? At least anyone with enough testosterone poisoning to think that bigger is better? And what's bigger? Maybe a Cray?

To Learn

To learn. How often do you get to twiddle with the guts of a compiler, assembler, or OS? Or all three at the same time? I don't know about you, but I've always pretended to know how these things work. And I wasn't bad at pretending. Now I can pretend with greater confidence. See the first reason above.

Because Its There

Face it. You've got a career in computing, and you don't know the mainframe? Isn't that like saying "I'm a really really great mountain climber, and I (puff up chest) have never climbed Mt. Everest!" What, are you nuts? Your career is not complete, and it won't be till you do. Either that, or your one of those lucky ones who aren't tortured in your sleep by such things. See also reason two, immediately above.

Because Its Knarly, Duude!

I think that's how those outdoorsey types that like to climb mountains and stuff talk, isn't that right, duude? But seriously, duude, have you checked out that architecture? Weren't you paying attention during reason number three? This is the grand-daddy, and its rightfully famous for some of the things it can do. Lets look at some of these.

I/O

Puny dinosaur brains can make mountains of muscle move. With four instructions (tsch, stsch, msch, ssch), you can keep thousands of I/O devices going full tilt without breaking a sweat. How can that be? Loosely speaking, the architecture implements DMA in the instruction set: all devices are DMA devices, with large fancy controllers that do the actual work so that the CPU doesn't have to. That's why they cost so much. Think of it as non-Symmetric-MP. In practical terms, what does it mean? Think of Linux on a box with not a lot of memory but a big, fast swap-disk. On any ordinary CPU, you might curse this situation as you listen to those disk drives chatter. On a mainframe, its more like a goal that you might want to shoot for. What's the point of having all those spindles going idly round and round? Let them do something. I see no reason why something like Linux couldn't eventually be tuned to work well in this kind of environment, with the kind of throughput and scheduling efficiency that MVS is famed for. (None of this is to imply that the CPU is a 90 lb. weakling. Its raw MIPS and FLOPS beat the rest out there, and most boxes ship natively as 10-way SMP's. So maybe instead of saying 'dinosaur brains', we should say 'elephant brains'.)

Address Spaces and Access Lists

Some people talk about capabilities as a means of doing security. Others talk about how a rogue kernel module can do a lot of damage to the kernel proper, like crash the machine, for instance, or maybe do far more malicious and pernicious things. Now imagine a hardware architecture that could protect against that. Address spaces give you the hardware equivalent of a (large) number of distinct kernel spaces, each of which is protected from trashing the other, (or even reading data in the other), while at the same time allowing high-speed direct access via an SVC-type call. So instead of having user space, with limited privileges, and kernel space, with full privileges, you can have multiple spaces, each with full privileges, yet each protected from the others.

Put it another way: traditionally, the X server and X clients live in distinct address spaces for security reasons. You don't want a rogue X client trashing other clients or even taking the X server down. The price for this safety is high. You have to make Xlib calls, which have to create protocol, which has to be pushed into pipes or sockets. Data has to be reformatted and copied from here to there. On the server side, you have to scan the header, decode the major an minor protocol numbers. Dispatch from a giant switch statement: case draw-line: case blit: Hundreds of thousands of CPU cycles just to perform some silly graphics operation safely. If you're into SQL, you get the same raw deal, hundreds of thousands of CPU cycles to query some puny 100 byte record. Imagine instead being able to get the same function, with the same amount of safety, but this time with only the overhead of a subroutine call. Can you say 'screaming performance'?

Traditionally, in Unix, there is only one privileged process on the hardware, and its called the kernel. User programs get to SVC into the kernel, and thus kernel calls are reasonably fast. Yeah, sure, there's FLIH and SLIH (top half and bottom half) type overheads, and etc. but imagine how bad life could have been if every kernel access had the same overhead as between X client and X server, or SQL client and SQL server? Now imagine a world where the kernel isn't the only privileged process, where there can be many of them, where every server could be one. Where it could be done with the same safety and rigor and separation as between kernel and user. And with the performance of a system call.

Its not a world we Unix hackers live in now, and its not a world that most people have thought about or are even aware of. Its not a thing you can do with ordinary CPU's. But look at computing history: once upon a time, many CPU's didn't have virtual memory. Now they all do. Well, the hardware for multiple address spaces isn't really any more complicated than the hardware for virtual memory. Meanwhile, its available now on the mainframe, and if we ever get Linux/390 working, it will be a computing playground.

VM

As a variation of the above concepts, we have VM, 'Virtual Machine'. It's just like what it sounds like. Professional sysadmins who know it love it. It allows you to run multiple operating systems one the same hardware. One of these can be the stable, production OS on which all of the day-to-day real stuff happens. Another can be the new-improved, beta-test thing. You can fiddle with it without worrying about crashing your production system. And when you're finally satisfied that the beta is beta no more but ready for production use, you can migrate everything over. Seamlessly. Without a burp.

The Intel world is slowly discovering VMware. Well, you can say that VM is like that. Except that its done right. Because, unlike the Intel chips, the mainframe CPU's has the stuff that you need built-in. Not kludged around.

The VM crowd seems to like Linux/390. Why? I can't speak for others, but I think that Linux can give VM new life by endowing it with a modern command line and modern utilities. And give 'em an excuse to hack on VM some more.

The Business Model

Don't know about you, but I think that Linux on the mainframe has the potential, the promise, for being the fastest, finest Unix out there. Sure IBM already has the SP/2. But it seems like it didn't really dent the territory that Sun and SGI rule. Imagine a box that could. Yeah, well, other people are saying Beowulf. And they're right. But Beowulf doesn't have the I/O capabilities. The address space partitioning. Yet. Note to MVS hacks at IBM: don't be scared of Linux/390. Your MVS market is locked up and not going anywhere. That's not the threat. The MVS customers who haven't fled yet aren't going to unless you really screw up on pricing or something. And the customers you've lost to SGI & Sun won't be coming back to MVS soon (Jeez, have you actually used the OpenEdition command line? Ech.) You can win 'em back with Linux/390. Believe me. It'll happen. And if there are Hitachi & Amdahl folks listening ... who do you think is your main competitor? IBM? or Sun? (And please don't say SGI. I've stupidly still got SGI stock, and its taken about all the punishing I can stand.)

Nookie

Well, when screwing with technology, there's this joke about getting carpet burns. So is it just too crude and offensive to quote Limp Bizkit? "We did it all for the nookie. The nookie. The nookie. So you can take that cookie and stick it (muffled shout) in your ear!"