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.