[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] Distraction over Wikipedia topic, was Rock Ridge and
Re: [Libcdio-devel] Distraction over Wikipedia topic, was Rock Ridge and libisofs/xorriso 'AL' extension
Mon, 31 Jul 2017 08:51:46 -0400
Please move this discussion elsewhere.
On Mon, Jul 31, 2017 at 8:40 AM, Thomas Schmitt <address@hidden> wrote:
> 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 = MODESEL;
> s_command = 0x10;
> s_command = 12;
> s_buffer = 0x08;
> s_buffer = 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 would be byte 6 in table 241 of SPC-3, 18.104.22.168.
> 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 :)