On Thu, 9 Jan 1997 10:26:45 -0500 (EST) 
 der Mouse <mouse@Holo.Rodents.Montreal.QC.CA> wrote:

 > Yeah, NetBSD/sparc - at least last time I looked at the code - doesn't
 > understand native NetBSD disklabels, only SunOS-style disklabels.  IMO
 > this is a lose (you need a SunOS-style label on your boot disk, but not
 > on any others, unless they're shared with non-NetBSD OSes).

NetBSD/sparc now understands NetBSD-format disklabels, as well.  In fact,
they can even co-exist with a SunOS-format disklabel (the NetBSD label
is placed in some empty space inside the SunOS label).

 > Heavens no.  The hp300 port uses a weird setup apparently invented by
 > HP, one I assume it's compelled to use for compatability with HP's boot
 > ROMs.  Under HP-UX there's this thing called LIF, I'm not sure what it
 > stands for, but it's basically a really rudimentary filesystem.  The
 > NetBSD/hp300 bootblocks are really LIF images, constructed "by hand" by
 > mkboot when "make install" is run in /sys/arch/hp300/stand.  See
 > mkboot.c in that directory for full details.

uhh....

NetBSD/hp300 uses "native BSD" labels.  HP-UX didn't _have_ disk labels.
The only thing in NetBSD that uses LIF is the boot code, and they only
exist on bootable disks.  The HP BOOTROM completely ignores the BSD
disklabel that sits inside it.

 > Or at least that's true of a 1.2 source tree; I think thorpej has been
 > working on bringing the hp300 port into a more modern state.  I don't
 > know whether any of this has been touched (though I don't recall seeing
 > any source-changes mail about changing anything bootblock-related), nor
 > whether it will be.

...err, ever since the hp300 port has had disklabels (which came with
the Lite merge back in the 0.9 days), the disklabel format has remained
constant... I haven't changed it at all, except for fixing bugs here
and there :-)

The "modernization" of the hp300 port I've been doing is basically in the
areas of autoconfiguration.

 > > can anyone tell me how I could make the hp writing directly to the
 > > zip disk ?
 > 
 > Can't help you there; my hp300 has no SCSI. :-(

...should probably consider upgrading to NetBSD-current... I've fixed
a couple of bugs in the hp300 SCSI disk driver...

 > > or how to make a filesystem on it that both, the hp and the sparc can
 > > read ?
 > 
 > This is probably possible, but it would be a bit ugly.  (Note: I
 > haven't tried any of this; this is pure speculation at present.)
 > 
 > Disklabel the disk on the HP.  This will write a LIF header into the
 > first 40 bytes of the first sector and dump a bunch more stuff into
 > later sectors, per the comments in mkboot.c.

..."No."  :-)

I've done this before... it's easy :-)

"Don't put a disklabel on the disk, and use partition "c" for everything."
No partition translation is done on partition "c" (but, make sure you're
running -current on the hp300!)

 > It occurs to me that given how hp300 mkboot lays out the beginning of
 > the disk, you could probably create a disk that would be bootable on
 > either the hp300 or the sparc, but it would require some very careful
 > juggling to fit the sparc boot program into the unused spaces in the
 > hp300 layout - definitely not something for the faint of heart.
 > (Besides, the sparc and the hp300 can't share binaries, and a zip disk
 > is barely big enough for a bootable system for _one_ architecture.)

...There's nothing special about how mkboot "lays out the disk".  In
fact, mkboot doesn't touch the disk _at all_.  All it does it create
a LIF, which is the boot program format understood by the HP BOOTROM.
The netboot code uses LIF, too :-)

Now, the way it works... disklabel -B reads the LIF file, and places
the in-core copy of the disklabel in some empty space inside the LIF
file (which happens to be at LABELSECTOR * DEV_BSIZE + LABELOFFSET,
then adjusted to fit; the kernel disklabel read code knows how to slide
the window through the LABELSECTOR until the disklabel is located).
Then, the LIF, including BSD-format disklabel in the normal place, is
saved to the disk starting at sector 0.  The boot block is large-ish,
so it typically spills into the area normally available to a file system
on partition "c".  This is unavoidable; you simply can't have a file
system on partition "c" of a bootable disk under NetBSD/hp300 (and,
disklabel(8) enforces this).

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939