Hi all,
I'm working on fixing up a regression on SPARC32 and I'm trying to understand the format of the SunOS disk identifiers in the form of sd(w,x,y):z in order to correct missing fields for romvec.
The comments in OpenBIOS suggest the following:
/* Generate the "oldpath" FIXME: hardcoding this looks almost definitely wrong. With sd(0,2,0):b we get to see the solaris kernel though */
and
/* Controller currently always 0 */
Am I right to assume the following mappings given a disk identifier in the form of sd(w,x,y):z:
w = controller = always 0 (or maybe my-unit phys.lo?) x = unit (equivalent of my-unit phys.hi) y = LUN (equivalent of my-address) z = partition identifier (equivalent of my-args)
Any pointers gratefully received :)
Many thanks,
Mark.
On 2013-Aug-5 13:25 , Mark Cave-Ayland wrote:
Hi all,
I'm working on fixing up a regression on SPARC32 and I'm trying to understand the format of the SunOS disk identifiers in the form of sd(w,x,y):z in order to correct missing fields for romvec.
The comments in OpenBIOS suggest the following:
/* Generate the "oldpath" FIXME: hardcoding this looks almost definitely wrong. With sd(0,2,0):b we get to see the solaris kernel though */
and
/* Controller currently always 0 */
Am I right to assume the following mappings given a disk identifier in the form of sd(w,x,y):z:
w = controller = always 0 (or maybe my-unit phys.lo?) x = unit (equivalent of my-unit phys.hi) y = LUN (equivalent of my-address) z = partition identifier (equivalent of my-args)
Any pointers gratefully received :)
I"m a little rusty on this, haven't done SunOS 4.1.3 since 1993...
However, I believe the mapping of sd(w,x,y):z correlates directly with the Solaris 2.x and later c0t0d0s0 mapping. If so, the fields (in Solaris speak) are Controller, Target, Device(lun), Slice.
The controller number is a pure solaris construct, it's the incremental number of SCSI controller accumulated since the OS was installed. That is, if you have only one SCSI controller, it will be controller number 0. If you have two controllers, the first one it saw the first time is controller number zero, and the second one will be controller number 1. If you remove one of your controllers (or move it into a different slot), the new location will get controller number 2. Yes, this is understood as an awful method of tracking device instances, and has numerous failings, but we never have managed to move past it.
The Target will be my-unit phys.hi. The Lun will be my-unit phys.lo The partition/slice number will be based on how the disk was labeled. Slices are named with letters in OBP-land, the first slice being "a". If it's UFS, slice "c" is the slice which encompasses the whole disk - usually *not* what you want to boot from. It's normally called "backup".
In HSFS (CD-rom filesystem), partitions are named the same, but partition "c" isn't special - its just another partition. Back in SunOS days, I recall the boot partition of CDs was "f". These days, Solaris disks are produced with all six partitions pointing to the same disk blocks so we tend to boot from partition ":a".
Tarl Neustaedter wrote:
Slices are named with letters in OBP-land, the first slice being "a". If it's UFS, slice "c" is the slice which encompasses the whole disk - usually *not* what you want to boot from. It's normally called "backup".
In HSFS (CD-rom filesystem), partitions are named the same, but partition "c" isn't special - its just another partition. Back in SunOS days, I recall the boot partition of CDs was "f". These days, Solaris disks are produced with all six partitions pointing to the same disk blocks so we tend to boot from partition ":a".
With emphasis on "these days". I remember struggling to work out which partition to use on a Solaris 7 (I think) CD a year or so ago.
On 05/08/13 19:00, Tarl Neustaedter wrote:
I"m a little rusty on this, haven't done SunOS 4.1.3 since 1993...
However, I believe the mapping of sd(w,x,y):z correlates directly with the Solaris 2.x and later c0t0d0s0 mapping. If so, the fields (in Solaris speak) are Controller, Target, Device(lun), Slice.
The controller number is a pure solaris construct, it's the incremental number of SCSI controller accumulated since the OS was installed. That is, if you have only one SCSI controller, it will be controller number 0. If you have two controllers, the first one it saw the first time is controller number zero, and the second one will be controller number 1. If you remove one of your controllers (or move it into a different slot), the new location will get controller number 2. Yes, this is understood as an awful method of tracking device instances, and has numerous failings, but we never have managed to move past it.
The Target will be my-unit phys.hi. The Lun will be my-unit phys.lo The partition/slice number will be based on how the disk was labeled. Slices are named with letters in OBP-land, the first slice being "a". If it's UFS, slice "c" is the slice which encompasses the whole disk - usually *not* what you want to boot from. It's normally called "backup".
This is exactly what I'm looking for - thanks Tarl. I'll try and code up a patch based upon this later today.
Many thanks,
Mark.
-
Mark Cave-Ayland -
Mark Morgan Lloyd -
Tarl Neustaedter