>> I tried running the SunOS format program under NetBSD but it isn't
>> happy and complains about not being able to find any disks.

> My 1.0 system ([...]) barfs thusly:

>   8522 format   CALL  write(0x1,0x395d0,0x16)
>   8522 format   GIO   fd 1 wrote 22 bytes
>        "Searching for disks..."
>   8522 format   RET   write 22/0x16
>   8522 format   CALL  open(0xf7fff278,0x6,0x63)
>   8522 format   NAMI  "/dev/rsd0c"
>   8522 format   RET   open 4
>   8522 format   CALL  ioctl(0x4,0x403c647e ,0xf7fff604)
>   8522 format   RET   ioctl -1 errno 25 Inappropriate ioctl for device
>   8522 format   CALL  close(0x4)

This is almost certainly DKIOCGCONF.  When I syscall-trace "format sd0"
running under SunOS, I get

....
write (1, 0xef8028d0="Searching for disks...", 22) = 22
open (0xeffff3d8="/dev/rsd0c", 0x6=O_RDWR|O_NDELAY/*BSD*/) = 3
ioctl (3, 0x403c647e=DKIOCGCONF, 0xeffff764) = 0: conf=<ctlr=esp0,ctype=0x8=DKC_MD21,flags=0x8=DKI_FMTVOL,addr=f0800000,space=14,prio=1024,vec=0,drive=sd,unit=0,slave=24>
ioctl (3, 0xc0187501=_IOWR('u',1,<24>), 0xeffff3d8="\357\377\363\314\0\0\0\6\357\377\364T\0\0\0\377\0\0\0\0\0\0\0\17") = 0: data="\357\377\363\314\0\0\0\6\357\377\364T\0\0\0\377\0\0\0\0\0\0\0\17"
ioctl (3, 0xc0187501=_IOWR('u',1,<24>), 0xeffff3d8="\357\377\363\314\0\0\0\6\357\377\365d\0\0\2\0\0\0\0\0\0\0\0\17") = 0: data="\357\377\363\314\0\0\0\6\357\377\365d\0\0\2\0\0\0\0\0\0\0\0\17"
close (3) = 0
write (1, 0xef8028d0="done\n", 5) = 5
open (0xeffff708="/dev/rsd0c", 0x6=O_RDWR|O_NDELAY/*BSD*/) = 3
ioctl (3, 0x80266403=DKIOCSGEOM, 0xeffff6f0=<ncyl=1151,acyl=2,bcyl=0,nh=9,ns=80,int=1,apc=0,rpm=4400,pcyl=2500,(bhead=0,gap=(0,0))>) = 0
ioctl (3, 0x8040647b=DKIOCSAPART, 0xeffff6b0=<a=<cyl=0,siz=33120><b=<cyl=46,siz=131040><c=<cyl=0,siz=828720><d=<cyl=730,siz=28800><e=<cyl=770,siz=100800><f=<cyl=910,siz=173520><g=<cyl=228,siz=361440><h=<cyl=0,siz=0>>) = 0
brk (0x43f78) = 0
brk (0x53f78) = 0
write (1, 0xef8028d0="selecting sd0: <SUN0424>\n", 25) = 25
ioctl (3, 0xc0187501=_IOWR('u',1,<24>), 0xeffff6a0="\357\377\366\224\0\0\0\6\0\0030\360\0\0\b\0\0\0\0\0\0\0\0\17") = 0: data="\357\377\366\224\0\0\0\6\0\0030\360\0\0\b\0\0\0\0\0\0\0\0\17"
ioctl (3, 0xc0187501=_IOWR('u',1,<24>), 0xeffff690="\357\377\366\204\0\0\0\6\0\2\270\300\0\0\2\0\0\0\0\0\0\0\0\16") = 0: data="\357\377\366\204\0\0\0\6\0\2\270\300\0\0\2\0\0\0\0\0\0\0\0\16"
ioctl (3, 0xc0187501=_IOWR('u',1,<24>), 0xeffff690="\357\377\366\204\0\0\0\6\0\5)\0\0\0\2\0\0\0\0\0\0\0\0\16") = 0: data="\357\377\366\204\0\0\0\6\0\5)\0\0\0\2\0\0\0\0\0\0\0\0\16"
ioctl (3, 0x400c6408=DKIOCINFO, 0xeffff688) = 0: info=<ctlr=f0800000,unit=24,ctype=0xd=DKC_SCSI_CCS,flags=0x8=DKI_FMTVOL>
write (1, 0xef8028d0="[disk formatted, defect list found]\n", 36) = 36
....

My syscall tracer doesn't yet unpack _IOWR('u',1,some-24-byte-type); I
believe that's USCSICMD.  With the aid of <scsi/impl/uscsi.h>, it would
probably be possible to handle it, but I don't yet.

Until NetBSD's SunOS emulation is good enough to handle DKIOCGCONF,
USCSICMD, DKIOCSGEOM, DKIOCSAPART, and DKIOCINFO, you can probably
forget about SunOS format working.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu