Please move this discussion elsewhere. On Mon, Jul 31, 2017 at 8:40 AM, Thomas Schmitt <[email protected]> wrote:
> Hi, > > Natalia Portillo wrote: > > http://www.retrocomputing.net/parts/sun/ss10/cdrom_faq.htm seems to > have the > > exact command. > > Oh nostalgy. I had a SUN IPX on my desk around that time. > With 400 MB disk and a 1.4 MB floppy drive. CD was for audiophiles. > > The beef is in > s_command[0] = MODESEL; > s_command[1] = 0x10; > s_command[4] = 12; > s_buffer[3] = 0x08; > s_buffer[10] = 0x02; > > MODE SELECT(6). PF=1 says the mode page would be SCSI compliant, if there > was any mode page. The command sends 12 bytes to the drive. > > The buffer data announce block descriptor length 8. > Block descriptor is new to me. Seems to be one or more range descriptions > which say how many bytes a block has in the given range. Range size 0 > means up to the end of the device. > So s_buffer[10] would be byte 6 in table 241 of SPC-3, 7.4.4.1. > That's the middle byte of 3 byte BLOCK LENGTH. > So this says: 2 * 256 = 512 which matches the announcement: > "Here is the program to set the transfer length to 512 bytes" > > Then the payload ends. So it's not about a mode page, as i am used to. > > MMC-5 has in Annex A: > "A.3 No Block Descriptors in MM ATAPI Devices > MM ATAPI devices do not implement Block Descriptors in mode data. > The default block size for MM ATAPI devices is 2 048. Other block > sizes may be supported." > and in Annex E (obviously for non ATAPI devices): > "Valid block sizes are shown in Table E.1. > 512 Mode 1 or Mode 2 Form 1 sectors divided into four blocks each > ... > " > > So yes, the old SCSI command would still be legal. But all modern > MMC drives are PATA or SATA, which i assume implies ATAPI. > So they are entitled to refuse. > > > To create an unambiguous block reader environment for very old drives, > i would issue above MODE SELECT and request block size 2048. Possible > error replies from the drive may be ignored then. > Afterwards i would assume that device block size is 2048 and apply > block address conversions for addresses which count 512-byte blocks. > > > > When we are giving block access to an iso file we are basicallu > emulatinh a > > CD drive, so should we emulate that behaviour is a legitimate question. > > libisofs drives the filesystem by 2048-byte blocks (although the PVD > could say different and then i'm doomed), the media access is done by > libburn, which at its API assumes block size 2048, too. > Inside libburn, i distinguish between MMC drives and emulated drives. > > MMC drives are operated by SCSI commands and the kernel's passthrough > mechanism, e.g. Linux SG_IO. There libburn assumes 2048 bytes per block. > > Emulated drives get operated by POSIX i/o: lseek(2), read(2), write(2). > So this uses off_t byte addresses which the operating system converts to > block addresses as it deems correct. > > > > It's a mess how 512 bytes is hardcoded all over the industry, in buffer > > sizes, ignored "sector size" fields, etc, etc. > > We have to expect trouble with bootable ISOs when they get put onto > disk-like devices which have other block size than 512. That's because > their partition tables and even the MBR boot code assume 512. > > But i did not see a single complaint stemming from this risk. Not yet. > > > Have a nice day :) > > Thomas > > >
