Subject: Re: Installing pmax on a dec3100
To: Robert R|dsten <robertr@fys.uio.no>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-pmax
Date: 02/11/1996 14:11:09
Rober R|dsten <robertr@fys.uio.no> writes:

>I'm trying to install the pmax port to a dec3100. I got it without any 
>HD. Since I don't have a Ultrix system at hand I thought using a i386 
>NetBSD system would be the best solution labeling a new HD for the 3100. 


[..]

Hi,
I don't beleieve that using a native NetBSD/i386 disklabel program
will work.  Disklabel contains some machine-code.  One of the
machine-dependent pieces is, where the bootblock area starts,
how big it is, and whether or not there is a secondary
area for bootblock code.

The pmax PROM needs different choices for at least the last three
than the i386 port.  (The i386 port also uses the "d" partition
as the partition that contains the entire drive, for largely historical
reasons.)

What you could do is to compile, by hand, a version of disklabel
(either the NetBSD source or the one Ted ported to Ultrix) that
has the pmax defaults, and  use that to write the disklabel.

You want to compile disklabel.c with NUMBOOT #define'd to be 2.

As it is, that's harder to change than it needs to be.  There are two
different mechanisms in use for defining NUMBOOT: some ports (e.g.,
i386) define NUMBOOT in src/sbin/disklabel/Makefile.  Some ports
(e.g., pmax) define NUMBOOT in usr/include/machine/disklabel.

Purely for selfish reasons, I think it'd be nice if disklabel was
``cross-compilable'', in the sense of being compilable on one
architecture, to run on that architecture, but to write disklabels and
bootblock code for another architecture (even one with
the same endian-ness and word size as the host machine.)

I don't have any great ideas on how to do that, though.  Getting rid
of all the compile-time conditionals and making them all run-time
selectable might be a good step, though.  (Then it's a `simple' matter
of adding command-line options to change disklabel's idea of the
architecture for which it should be writing a disklabel, followed by
less trivial endian/wordsize issues.)

maybe I should forward some  of this to current-users?