Passing a Torch
It is hard to let things go sometimes.
Porting Linux to the VAX architecture taught me a lot about the detail of how Linux works, as well as how computer hardware and operating systems interact. It both removed the air of mystery about the kernel, and opened my eyes to the complexity of the GCC compiler and toolchain.
The VAX architecture is simple and easy to understand for a beginner - so much so, that when I started there were several good computer science text books which used it as a teaching system/example. I still have one or two of them on my bookshelf.
All in all it was an ideal first computer to learn operating system systems programming with, in the same way that the Talbot Horizon I had at the same time taught me about how engines and cars work - and that rust does not make an effective conductor.
It started out as a simple idea. In 1998 I had completed my Ph.D. which had been my focus for the previous 7 years. There was a lot of very capable (by 1998 standards) but increasingly spare VAX hardware lying around, and I felt the need to acquire some marketable skills. Linux was really taking off at this point, and what better than to start a port of Linux to the VAX as a project to teach myself all about it?
There were some previous attempts - but nothing had got much further than good intentions. The furthest along were some guys at the University of Canberra who had started in 1997 with posts on comp.os.linux.development. They had unfortunately pretty much stalled by the time I came along. They had an a.out toolchain and the start of an ODS-2 filesystem driver.
The first year I made good progress by myself, including setting up a mailing list and web server to host the project (which was migrated to sourceforge in early 2000 - and still available at http://linux-vax.sourceforge.net/ in all its 1990's web design glory).
Things picked up speed as contributors joined and we hit problems and milestones along the way. Memorable things included;
- having to write a memory management layer to group the tiny 512 byte VAX hardware memory pages into the smallest unit that the linux kernel upper layers would handle of 4096 bytes
- getting the computer to transition from the equivalent of real to protected mode.
- Realising that the a.out format, whilst supported at the time, was now a dead end for the linux kernel developers, and that meant we needed to write an ELF toolchain for the VAX from scratch.
- Which required learning how the entire gnu toolchain worked top to bottom - including what libbfd does and why it was a big deal.
- Taking my fastest VAX and attempting to get it to self host GCC and ulibc - it took 3 days to compile gcc.
- Getting that first shell prompt.
The history can be found in this interview from Newsforge in June 2001 - which courtesy of the wayback machine can be found here.
Unfortunately, pretty much after the article was written things started to get much more difficult and progress slowed down. The Linux kernel accelerated away from us. Even though Alan Cox agreed to sponsor our merge into the kernel, we never made it to a point where we could merge.
Oddly enough, looking at modern Linux kernels, doing a port from scratch would in many ways be easier now. The reason is that so many other ports have happened over the years that Linux has become far more generic and less x86 centric. Its also true that the x86_64 and x86 archittectures have become more VAX like in their design - for example with the way interrupts are handled.
So by 2002 we had a bootable system, with basic support for a subset of hardware. We had a basic NFS served ram disk (unless you had an NCR 5380 based scsi controller - in which case it could be booted from disk), but taking each next step started to become harder. I had (during the first few years) the idea of getting redhat linux up and running on the VAX. However the bloat and memory footprint for a minimal "proper" linux distro soon shot past the 16 Megabytes of RAM even a well endowed VAX came with.
Then for me it all slowly came to a halt after I joined Betfair in late 2002 and the full time job that is an internet startup.
The Vaxes I have have followed me around ever since, but the last time they were all powered up was several years ago. I still have one on my desk - a VAXstation 3100M76 sitting under a VXT2000+ which gets the odd chance to run. I'd love to be able to plug it into a monitor (which will need composite BNC sync on green) and fire it up again properly, but its development days are over. In fact, if I can't find my MMJ cable, I'll have lost my ability to talk to it at all.
A lot of the fondness comes from the fact that VAXes were simple enough to understand completely, in the same way that a beat up Horizon with a 1.3l engine and a dodgy gearbox was. No engine management or precisely calibrated fuel injector system - just a screw to twiddle on the carburettor to adjust the mixture. There is the same sense of pride in being able to replace your own brake pads or write your own boot loader.
Being a CISC instruction set, you had great instructions like SOBGTR - "Subtract One and Branch if Greater than".
For example this snippet;
movab _VAX_start_mm, r10 # This is where we start mapping
ashl $-9, r10, r4 # calculate the pfn of the start of this fn
movab P0_table,r3 # Phys address of P0table.
movl 0x08,r2
P0fill: movl (r3), r1 # fill the P0table with the right pfns
addl2 r4, r1
movl r1, (r3)
addl2 $0x04, r3
sobgtr r2, P0fill
Creates a stub P0table which maps the user space memory segment around the current function (_VAX_start_mm) , could equally be written (in bad C code) as;
r10 = &_VAX_start_mm;
r4 = r10 >> 9; /* bit shift down by 9 places to divide by 512 */
r3 = &P0_table; /* address of table */
r2 = 8;
do {
*r3 += r4; /* r4 holds the pageframe number of the current function */
r3 ++;
r2--;
} while (r2 > 0);
Which is not that much shorter, and arguably easier to understand.
Much to my surprise interest in Linux VAX picked up again a few years ago, and has continued in fits and starts.
Neither I nor Alisdair who ran the mailing list and hosted the site has had much spare time to help out, and its become clear that at this point we are no longer helping the cause. So I took the decision, after a recent poke, to finally hand over the mailing list and website to a new maintainer. I hope they make decent progress and I wish them the best of luck.
In reality the ship has long sailed for a merge into the kernel tree - in all probablity it sailed a decade ago, but there may still be other people for whom the VAX is still the ideal project to learn about Linux, and how computers really work, and I wish them luck. I have spare hardware if they want to make me an offer.
The Vaxes still fire up, after 15+ years. Thats quite an achievement, and they've certainly outlasted my Talbot Horizon which rusted to death a long time ago. It certainly is a lot better than the current servers in the datacentre, which are struggling to make it past 4 years before the failure rate shoots up.
They don't make 'em like that anymore.
Some links for the curious.
Incidentally OpenVMS is still going strong. Perhaps one day Linux will catch up with it. But I doubt when it does that it will ever boot on a VAX. It would be nice to be proved wrong.
