> 
> On Wed, 9 Aug 1995 14:51:56 -0700 (PDT) 
>  wrstuden@loki.stanford.edu (Bill Studenmund) wrote:
> 
> Note I said "at least the same byte order".  :-)  Yah, cd9660 does this, 
> but I've gathered from a discussion or two that it's non-trivial to do 
> this with FFS, at least.  msdosfs may be a different story ... unknown.

Point taken. It might be that only certain filesystems get the cross-
endian treatment.

> Also, your reasoning goes that all ports should also be able to read 
> SunOS disks (which was my original motivation; I had to plug one into my 
> hp380) since they're so prevalent.

Why not (given the above endian-isms)?

>  > > 	* At least in the MI SCSI code, the disklabel is read then the
>  > > 	  device is opened, not when it is probed/matched/attached.
>  > 
>  > My ignorance shows at this point. When _which_ device is opened? One of the
>  > sdXY's? But don't you need a disktab to see if a device really does
>  > anything? Also, is the timing of when the disklabel gets read critical?
>  > As long as it's after the ability to talk to the drive exists, and before
>  > people want to use the partitions, does it make a difference?
> 
> No, you don't need a `disktab' file ... that's only used by a few 
> user-land utilities whenever a disklabel isn't available (like, when 
> newfs'ing floppies, for example).  disklabel(8) can also use it to 
> install `default' partitioning on new disks, but given that /etc/disktab 
> is not really up to date with the latest disk hardware releases, it's not 
> particularly useful anyhow.

I misspoke. I meant disklabel (the kernel structure).

> While is says "if not already loaded", the in-core copy of the disklabel 
> is updated _every time_ a partition on any given disk is opened, as far 
> as I can tell.

Why? This seems wasteful to me. Hmmm. Does it change that often?

>  > > 	* Not all ports keep the `whole disk' in the `c' partition.
>  > 
>  > I don't think this will be a problem. The disktab reading routine
>  > can read whatever it needs off of "c" to build a new disktab. It then
>  > closes "c", installs the new disktab, and away it goes. At that point,
>  > the port does whatever it wants.
> 
> Ummm ... no, because `c' doesn't mean the same thing on, for example, the 
> i386 port and the hp300 port (two of the four I work with the most).  And, 
> that exactly are you reading off of `c' to build a new `disktab'?
(see disklabel/disktab confusion above).

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.

>  > I.E. most system's would have something in d, and the disk in c. On
>  > a platform that does it different, the something would go into c, and
>  > the whole disk into d.
> 
> Not necessarily ... the i386 port, for example, keeps the `whole disk' in 
> `d', and `all of NetBSD's portion of the disk' in `c'.  So, a simple swap 
> doesn't work.  Not to mention, that sort of violates the convention 
> behind partition naming... 

True. Though I am a bit partial to the MacOS's port (the one I use) which
puts the whole drive in c, regardless of gaps in the structure.

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?

> 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?

Take care,

Bill