I'm pleased to (finally) announce the release of NetBSD/Alpha.
As some of you may know, NetBSD is a freely-available and
freely-redistributable BSD-derived system that runs on a variety of hardware
platforms, including i386's, Amigas, SPARCs, and DECstations. The Alpha
port is unique, because it's the first port of NetBSD to a 64-bit
architecture.
The Alpha port of NetBSD is a true 64-bit port: pointers and longs are 64
bits. This involved a _LOT_ of changes to "machine-independent" portions
of the system, and while most of the NetBSD/Alpha machine-specific sources
are in the NetBSD source tree, many of the change to machine-independent
files are not, yet.
So, some details on the status of the port, a list of supported hardware:
The port is self-hosting; it is stable enough to build all of its
constituent binaries (including GCC and the rest of the tool chain)
many times over. It is in "production use" for its own development,
and will soon be in use by computer science researchers. It's _not_
simply a kernel hacker's toy at this point.
Lots of things still don't work properly. In particular, a lot of
(poorly-written) user-land programs don't work. As far as I'm
aware, however, there are no found-but-yet-unfixed bugs in the
libraries, which makes getting programs working a bit easier.
Unfortunately, at this time, GDB isn't capable of actually debugging
programs (though it is good for disassembling them, if you know
where they crashed). It's worth noting that the internet protocol
suite works wonderfully (and, indeed, I do most of my work remotedly
logged in), and the SunRPC library also works. Because formatting
the manual pages would have required making g++ and groff work,
there are no formatted man pages included, and there's no easy way
to format them. If you need the manual pages, I'd suggest that you
look on another NetBSD system. If you absolutely can't do that, the
OSF/1 manual pages should be OK for most tasks.
There's rudimentary support for running OSF/1 binaries, which I
originally used when bootstrapping the system. However, it is only
capable of running statically linked binaries, so it's not very
useful except for bootstrapping. It's hoped that eventually we'll
be able to run dynamically-linked OSF/1 binaries. (If you wish to
work on this, please get in touch with me!) NetBSD/Alpha can safely
read and write OSF/1 (v2.0; I would guess v1.x and v3.x as well)
file systems (assuming you don't have OSF/1's security features
enabed). Additionally, the NetBSD/Alpha disklabel format is
compatible with OSF/1's.
Supported hardware:
DEC 3000/[456789]00 -- I've only tested it on the 400 and
600, but the rest should "just work" -- supporting
the following peripherals:
Serial ports -- barely; the serial driver needs a
lot of help
LANCE ethernet -- but only the on-board model; I've
not tried any TurboChannel boards
SCSI system -- It recognizes and can use both
on-board SCSI controller chips. However,
it has trouble working with both at the
same time
At this time neither the Smart Frame Buffer nor the
ISDN/Audio interface is supported.
Unfortunately, at this time none of the following systems are
supported:
DEC 3000/300s (these shouldn't be too much work)
AlphaPCs -- the EISA-bus Alpha systems
AlphaStations -- the PCI-bus Alpha systems
The Futurebus-based Alpha server systems
The multiprocessor Alpha systems
Obtaining NetBSD/Alpha sources and binaries:
This release is being made in two parts, source and binary. The
source distribution is a gzipped tar file containing all of the
sources used to build the system, including the compiler and
user-land sources. The binary distribution is a gzipped disk
image from an rz25 disk; it's approximately 406M ungzipped
(63M gzipped), and you install it by dd'ing it on to a raw disk;
more on this later.
If you wish to obtain the source or binaries for the NetBSD/Alpha
distribution, send me (cgd@cs.cmu.edu) mail, and I'll arrange to
get them to you. They're sufficiently large that I've not yet
found an FTP site for them, and also, given the preliminary nature
of this distribution, I want to keep in close contact with
the people who are using them.
If you are interested in the NetBSD/Alpha port, I suggest that you
subscribe to the NetBSD "port-alpha" mailing list, by sending an
email message to majordomo@netbsd.org with no subject and with a
body of "subscribe port-alpha" (without the quotes). For help on
using majordomo, send it mail with an empty subject and body.
Installing the NetBSD/Alpha distribution:
[ Note that these instructions are minimal; it's assumed that if
you're going to be installing this, you're knowledgeable about
booting Alphas and doing other sysadmin-ish stuff, are willing
to look in the documentation, or are brave. If they're
really not good enough for you, get in touch with me and
I'll try to help you. ]
To install the NetBSD/Alpha distribution, you'll need a disk at
least the size of an RZ25 -- about 406Mb. Once you've gotten the
binary distribution from me, gunzip it and dd it to the raw disk.
The binary distribution includes a disklabel and boot block, so you
don't need to do anything special to make it bootable. I created
the binary distribution's file systems with an older version (4.3
Reno) of the Berkeley Fast File System format, so that you can
mount, read, and write them under OSF/1.
Once you've dd'd the image to the disk, set your system to use a
serial console. Boot the Alpha with the NetBSD disk, supplying the
boot flag "-s". It should print something about "NetBSD/Alpha Boot
program", load the kernel, print a copyright, and print various
startup messages. Included among those startup messages will be
SCSI bus/id to device name mappings for all of the SCSI devices
that NetBSD recognizes. Eventually, it'll ask you for the name of
the root device. It expects something like "sd0", "sd1", etc., and
you should pick the name that corresponds to the NetBSD disk.
After a short while, you should be asked for the name of a shell
to use; just hit return. You're advised to fsck the disk at this
point (the root partition is partition 'a' and the /usr partition
is partition 'd'), remount the root partition read-write (use mount
-u root-dev /), and create some necessary system information files:
/etc/hosts
/etc/resolv.conf (if you want to use DNS)
/etc/myname (the hostname of the machine)
/etc/mygate (the LAN's gateway, if your network setup
requires that it be named explicitly)
/etc/hostname.le0 (to describe the enet addr, etc., for the
Alpha's ethernet. The format can be discerned by
looking in /etc/netstart. As an example, for
my development machine, it's:
inet macallan.dssc.cs.cmu.edu 0xffff0000 128.2.255.255
^^^^^^^^^^^^^^^hostname ^^^netmask ^^^broadcast)
/etc/fstab (a prototype is in /etc/fstab.sd)
(You can also create the files mentioned above by mounting the
disk's file systems under OSF/1 and filling in the appropriate
information.)
Once those files are created, you should be able to boot the system
multi-user. To do so, halt the system and boot again from the
NetBSD disk, this time supplying the boot flags "-a".
Once the system has booted, you should be able to log in over the
network. (Log in as root, at first, then use vipw to create user
account(s) and re-log in as the appropriate user.) If you used a
disk other than an RZ25, you may also want to edit the disk's
disklabel, and create one or more partitions to use the extra space.
Using NetBSD/Alpha:
You'll probably want to NFS mount the sources from another machine;
that's what I do, and it works just fine. If you'd like tips on
good ways to keep the NetBSD sources under source control, just ask.
A fair number of binaries don't work properly. For example:
GDB won't properly run programs or debug core files; someone
needs to write support for NetBSD.
diff dumps core if there are differences in the files being
compared (but it _doesn't_ dump core if they're the
same!)
ps and w don't work properly, for several reasons:
(a) they don't know how to read an ECOFF binary's
namelist, so can't find the addresses of
things in core
(b) I've thus far been lazy, and didn't bother
creating some of the necessary entries in
the device switches (e.g. /dev/drum),
because I knew nothing could use them
because of (a) anyway...
As noted above, the SCSI code is reliable only when being used with
one SCSI bus at a time; this is obviously a bug. Additionally, the
SCSI driver seems unhappy about dealing with certain types of disk
drives (e.g. the IBM Lightning). I don't know why these problems
exist yet, but it's worth noting that somebody's in the process of
rewriting the 53c94 chip support from the ground up because the
current support is "somewhat lacking." (This should solve at least
the latter problem.)
Because I've been working on getting the system up and running, then
out the door, I've not had much time to do performance analysis on
the kernel, nor tried to improve performance in any way. Some of
the code is awfully rough. That being said, on a lot of operations
I'm seeing performance similar to that of OSF/1 on the same hardware,
so I've not gone too far wrong anywhere.
I've run 'paranoia' on NetBSD/Alpha, and it reports one defect (the
same result as for OSF/1).
Thanks to:
Carnegie Mellon University, for providing funding for this project.
Keith Bostic, for writing and/or working on a large chunk of the
code, and for general moral corruption and good humor.
Jeff Mogul, for providing moral support, documentation, and
pointers thereto.
The various others working on NetBSD, for suggestions, sanity
checking, etc.
Whoever I'm forgetting, for things that I don't remember right now.
That's it for now; get in touch if you'd like to get copies of the software
and/or would like to contribute to the development effort. I'll be sending
out status reports to various places (probably including the place(s) you
saw this announcement) as things progress.
Chris Demetriou
cgd@cs.cmu.edu
