> 
> > What are "native" disklabels? If they're different from Apple's partitioning
> > stuff, why do we want them?
> 
> LOL... WHAT? You don't want them? You're gonna get them anyway!  ;-)

No, I don't. :-) Actually, when I hear people wanting "native
disklabels," I get the feeling they are really complaining about the
state of partitioning tools on the mac. I agree we have problems, and
I will help fix them, but I think we should fix them rather than
side-step the problem.

> A disklabel in *BSD diction is a data structure describing the disk
> hardware and the way it is partitioned. 
> 
> You are right in that the Macintosh uses a partitioning scheme that is
> (at least) equal to the *BSD scheme - IMHO it is more flexible. 
> The hardware data stored in a disklabel leads us directly into the Stone
> Age of computer history: Track-to-track transition time,
> sector/track/cylinder interleave, rpm - you name it, it's there. Look at
> disklabel(5) and /etc/disktab. But no way to feed it a zone recorded
> disk in a sensible manner - ouch... (Bill, I've read your mail to
> tech-kern some months ago, and be assured, I feel _at_least_ as strong
> about the issue. It currently hits me full force with the 800K floppy:
> 8..12 sectors/track at 300-550 rpm.)

Side note: I think I was really flaming ffs's insistance that the disk
be a certain number of whole cylinders. I want it to just accept that
it's been given some disk space to live on, and some _HINTS_ about
how that space is set up, but that it shouldn't get too fussy
about the details not coming out even. I think your floppies should
just be happily formatted at the variable sector spacing.

> But having a *BSD disklabel in a commonly accepted location enables us
> to move disks among machines with identical byte order, and that's why
> they are wanted. 

setenv DEVIL'S_ADVOCATE

Uhm, why limit yourself to identical -endian machines?
Why can't I take a DOS Zip drive and throw it in my Mac's Zip,
and read it under NetBSD? msdosfs works on both big & small-endian
machines. Also, why not do the same thing for AmigaDos drives. AmigaOS
is in the kernel too...

What about a SunOS drive? HP-UX?

unsetenv DEVIL'S_ADVOCATE

Actually about a year ago I suggested something like this. We have
filesystem abstraction, why not have disklabel abstraction? Why
not teach ALL ports about ALL disklabel types?

We obviously run into a problem when it's hard to tell one
label from another (they lack magic numbers like MacOS uses). But
different ports could probe in different orders, or they could
only probe a few of the known label types, and let the (super) user
come along later and tell the system to try a different type label.

Also, little-endian ports could easily deal with MacOS, Amiga,
HP, Sun, and other big-endian labels as network byte order just
so happens to be big-endian. msdosfs has the hooks to run on
a big-endian machine, too.

> And: I need a disklabel on the floppy if I want to put a file system
> onto it. Sure, you could always fake it in the kernel the way it is done
> for SCSI disks now. But support is there and (with minor tweaks) even
> operative, and you can have both: The kernel first looks for a MacOS
> magic number, then for *BSD counterpart.

Design question for you (maybe it could be a first step to disklabel
abstraction): how would you tell the kernel that it should write a
MacOS disklabel as opposed to a *BSD disklabel as opposed to a Sun
disklabel (I think boot blocks are different) as opposed to an
Amigs or an Atari disklabel?

(Aside: what other machine could even read a disk written by an IWM?
SIWM, yes, but IWM?)

Take care,

Bill