On Mon, 12 Jul 1999, Ross Harvey wrote:

> OK, good points. We don't grok PeeCee-style disk layouts, but it would be
> A Real Fine Thing if we did.  (I'm surprised this hasn't come up before,

i think it has, although i don't remember too clearly.  i'm wrestling with
a similar problem:  trying to read some NetBSD/alpha-labeled disks on
NetBSD/mac68k.  Thanks to the summer heat and a clogged fan inlet, i've
been downgraded from a 166MHz 21064A to a 16MHz 68020 :).

BTW, thanks all-- <2hrs work and my 8MB MacII is running X.  i pilfered my
68851 off some gigantic notVME 2-CPU pinnacle-of-human-achievement
bigger-than-my-'merican-TV-screen type board in the University Dumpster. I
dunno even what the thing was but it looked expensive.  arrgety ar, ar.

anyhow i'd like to throw out an idea.  i think someone else mentioned
something like this--``you can accomplish wonders with vnd and dd'' or
something along those lines.

instead of making ports able to read disks that they could never
conceivably boot off of, keep this code out of the kernel.  Each port's
kernel should only understand labels that its bootstrap code also
understands.  which means, only _one_ port is burdened with groking those
sick MBR labels.

then, make a 'disklabel' binary that understands _every_ disklabel, all
the ones that NetBSD supports, raw native ('-r' mode?) rather than through
the kernel. it would have some command-line options to attempt to
auto-detect a disk's label, or force interpretation as label-type X.  you
could possibly do all the usual read/format/edit stuff, but most
importantly, ``load this label into core as a fictitious label.''

native understanding in disklabel is also Good because it could have
better error-handling characteristics than the kernel code.  for example,
if you want to auto-detect a Mac disklabel, you look for the driver
sig/magic in Block 0.  but if you've ``forced'' Mac disklabel
interpretation, it's not necessary to insist that a Block 0 exist--you can
just assume 512-byte blocks if Block 0 is not there, or search for a magic
number, or whatever. the point is there are a lot of labels that the
kernel Should declare ``invalid,'' but which still contain useful
information that you might someday really, really appreciate being able to
read. obviously our immediate Goals are met without any code to do such
things as this, but my point is that the idea provides superior
infrastructure for future work, that it isn't a total rework-waste to
suggest that we should have two bits of code (kernel and disklabel) for
reading each kind of label.

finally, i think some demented little disks may have more than one label,
like a PC label and a Mac label for example--some hybrid CD's and maybe
Jaz disks with pre-installed software?  even wthout corruption, i think
there are some sick labels in this world that are best dealt with by a
userland program that can accept command-line options, run in scripts, and
be invoked more than once.

This disklabel-bloat accomplishes the same thing as the kernel tweaks,
except all the code is in userland. as i said before, you can't boot
without a native label, and there aren't many cases when you have a booted
system without /sbin/disklabel becuase /sbin/disklabel and /netbsd are
usually on the same FS.  so there's not really much disadvantage.  an
advantage is the process is more interactive and easier for the user to
understand intuitively what's going on.

also, it's less work if you look at it as a gigantic project to read all
disklabels on all ports (a very good thing, i think, along the lines of
FFS_EI and the endian-swap option to fsck_ffs) since eventually you only
have to do O(n) human work, instead of O(n**2) work to add this junk to n
ports. i consider it very Wise that disklabel is MI code and think that
the Reading of Foreign and Outlandish Labels project should take advantage
of this wisdom.

-- 
Miles Nordin / v:1-888-857-2723 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US