> > "Native disklabels" are the native disk partition map used by NetBSD.  You
> > would see them on either of the Sun ports I expect.
> 
> Playing the devil's advocate again, you'd also see sun disklabels,
> which are different. :-)

Which is just as well (disklabels can also contain arch-dependent boot
code!) as long as they know how to deal with the common standard.

> I have a zip, and the problem with it is that it doesn't
> support the command typically used to get the size and layout of
> the disk (mode sense, I believe). Normally disklabel just asks an
> SCSI drive how many tracks, sectors, heads, etc it has. Zips don't
> answer nice. :-( 

Actually, the kernel handles it like this: It asks the drive for
geometry data to fill in a 'draft' in-core disklabel. Either the disk
sends faked geometry data (remember, they're all zone recorded
nowadays), or the kernel starts making a fuzz about it and finally fakes
the geometry data itself, based on the number of total sectors. 

In a next step the SCSI code looks for a label on the disk containing
partition data. It calls MD routines in arch/mac68k/mac68k/disksubr.c
that first look for a MacOS magic number. If it is found, the MacOS
partition table is read and converted into an in-core disklabel. If
there is no MacOS ID, we look for a NetBSD ID and on success get the
NetBSD disklabel from disk.

That code was already there, although a bit untidy. It didn't work
correctly because of two bugs and was therefore #if 0 ..
#endif-bracketed; basically all I did was fix the bugs and remove the
#if 0 statements.

No big deal, huh!? And again: You get no replacement, but another option
(if Scott gets around to look at my diffs and commits them :).

 
        hauke

-- 
"It's never straight up and down"  (DEVO)