>  > Why? This seems wasteful to me. Hmmm. Does it change that often?
> 
> Well, considering that a partition doesn't get _opened_ all that often, 
> not it's not really wasteful at all.  But, this behavior _is_ useful.  
> Take for example something I did on my hp380 just a week ago.  I had two 
> partitons right next to each other, `f' and `g'.  I wanted to combine the 
> space.  So, I backed up the data on each, unmounted both, eliminated 
> partition `g' (and gave it's space to `f'), re-labeled, newfs'd, and 
> remounted the new partition, all without rebooting.  It's a feature :-)
> 
> Basically, it's good consistency check, worth the low expense...

Ok. Sounds useful.

>  > If the partition were read only once, the idea is that there are two
>  > different lifetimes for the disklabel in the kernel, before the partition
>  > is read, and after. The area of the disk that is 'c' before doesn't
>  > have to have anything to do with the area that is 'c' after. This idea
>  > fails if the partition is re-read frequently.
> 
> Huh?  What exactly do you mean by "different lifetimes for the disklabel 
> in the kernel, before the partition is read, and after."?  That doesn't 
> really make any sense to me...
 
The whole point of the `c' business was to get around the chicken-and-egg
problem of, if all your scsi devices read off partitions, and you want
to read off of the first few blocks of the disk, how do you read the disk
without a partition actually pointing to the first few blocks of the
disk?

My first thought was to build a fake disklabel, use it to read whatever
needs to be read to get a real disklabel, throw out the fake disklabel as
it's not needed anymore, and make the real one.

The answer (which I didn't know at the begining of the thread) is that
the current partition-readers can read the disk directly. So there is no
chicken-and-egg problem, so we probably don't need to be getting so worked
up. :-)

>  > Actually, does it matter what convention is used? This ability is
>  > mainly intended for occasional/special use. So what if the MSDOS-based
>  > disk stuffs the full drive in `d' when your system normally puts it in
>  > `c'. Chances are you wanted to just transfer data; these minor
>  > differences can be lived with, no?
> 
> It has absolutely _nothing_ to do with being an MSDOS-based disk.  I 
> don't have _any_ DOS/Windows/OS2 stuff on _any_ of my NetBSD/i386 boxes.  
> However, all of them use `d' as `whole disk'.  Look at 
> <machine/disklabel.h> for all the ports ... you'll see that most use the 
> value `2' for RAW_PART, which is `c'.  But, the i386 uses `3' for 
> RAW_PART.  It's not about the disk...

Ah, but did you (or the kernel secretly behind your back) use dos
partitioning software/conventions? You (or someone else) described how
the i386 port has `c' as the NetBSD part of the disk, and `d' the whole
disk. To me, this means that your disk _can_ have DOS stuff in it. As I
understand it, if you take your all-NetBSD disks to a DOS machine,
the DOS machine will know that the drive is formated, and that it is
full of non-DOS partitions. Granted it will have no clue as to what to
do with the non-DOS stuff, but DOS will know not to step on the data.

>  > > Another point to make here, I suppose, is that not all ports that use 
>  > > NetBSD-format disklabels keep them in the same place (for various 
>  > > reasons).  Just something else to think about :-)
>  > 
>  > Can they be told apart?
> 
> Huh?  I assume you mean ``Is it easy to tell the difference between them?''
> Umm .. the _is_ no difference between them, except for the size of the 
> partition map in them.  For example, the MAXPARTITIONS value on the hp300 
> is 8, but on the Amiga it's 16.  This means that sizeof(struct disklabel) 
> is different on these platforms.  So, the disklabel checksums will be 
> wrong if an hp300 reads an amiga's disklabel, since it won't read the 
> whole disklabel ... The biggest problem is _finding_ the disklabels...

Oops! Take a step back. Is there a difference ON DISK? Looking at just
the disk, can't we tell the difference between formats between various
OS's?

The above question is important. If we can't, then automatic disklabel
sensing won't work. I agree that, once we're in the kernel, there is
(should be :-) no difference.

What I mean by sensing, is that (I believe) any OS will leave certain
key patterns on a disk that tell it that it formatted the disk. I know
the MacOS leaves certain letters in the first sector. I believe that
DOS and AmigaOS leave seperate key patterns on disk to indicate that
the disk is formatted. I assume that all the other ports do the same
thing. Am I correct? (If not, how do you tell if a disk is formatted?)

If all these patterns are different, then we can look for each one in
turn.  If we find one, we know the partitioning scheme in use on the
disk. We then look to the port for that machine and ask it to read the
disklabel, as it already understands this partitioning scheme.

Though you do bring up one interesting question. What in the system REALLY
cares where the whole disk gets shoved? Isn't it just convention?
the few commands I've dealt with that want the whole disk require being
told the device name for the whole disk, so the human typing the command
can just change which drive gets typed, no? And since the native drives
follow the port's convention, shell scripts would see what they expect.

Food for though!

Take care,

Bill