andrew@alice.UUCP (Andrew Hume) (06/28/90)
while sgi is tweaking its scsi disk controller, perhaps it could allow the use of optical media at the same time. this media can be used by exactly the same commands (common disk subset) that the driver uses for the regular (magnetic) disk but no, the driver cleverly looks up what thing it is and says, "nah nah! i could but i won't." admittedly, the optical disks present one problem not normally (but possibly) present in magnetic disks: the media may not be spun up when you want to access (and thus needs a scsi START command). this handles the media removal stuff as well as magnetic disks which don't spinup on powerup. i guess what i am really asking for is simple 'raw disk' access to all types of scsi media that can be controlled with the common disk subset that is already used by the regular disk driver.
olson@anchor.esd.sgi.com (Dave Olson) (06/29/90)
andrew@alice.UUCP (Andrew Hume) writes: | while sgi is tweaking its scsi disk controller, perhaps it could | allow the use of optical media at the same time. this media | can be used by exactly the same commands (common disk subset) | that the driver uses for the regular (magnetic) disk but no, | the driver cleverly looks up what thing it is and says, "nah nah! | i could but i won't." 3.3 will allow you to access types WORM, CDROM, OPTICAL, and 'normal random access' devices through the dksc driver. Whether they work correctly, is something else, of course. The Maxtor Tahiti IS supported (software-wise) in 3.3, using the hard disk driver, as long as you use the 512 byte sector media (both standard and ZBR media). | admittedly, the optical disks present one problem not normally | (but possibly) present in magnetic disks: the media may not be spun up | when you want to access (and thus needs a scsi START command). The dksc driver has known how to issue a startunit command when needed since 3.2 IRIX. | this handles the media removal stuff as well as magnetic disks which don't spinup | on powerup. The hard disk driver does NOT do a prevent media removal, so it is up to the user to not hit the eject button. Alternatively, you could write a trivial command using the devscsi (ds) driver and the prevent media removal command. Simply run this command with the appropriate args before mounting and after unmounting the drive. | i guess what i am really asking for is simple 'raw disk' access to all | types of scsi media that can be controlled with the common disk subset | that is already used by the regular disk driver. This is mostly there in 3.3, although the hard disk driver DOES require either a volumeheader be written to the drive, or the DIOCSETVH ioctl be run to inform the driver of partition layout, etc. Support (at the raw device level only; i.e., not filesystems) for sector sizes other than 512 bytes will be in a future release. Meanwhile, you can right a fairly straightforward user program using the devscsi driver if all you want is raw access. I wrote a (very) trivial filesystem for MO drives with 1K sectored media in a couple of days; granted I already knew the devscsi library and driver fairly well, since I wrote part of it :). -- Dave Olson Life would be so much easier if we could just look at the source code.