Re: [Libcdio-devel] Distraction over Wikipedia topic, was Rock Ridge and libisofs/xorriso 'AL' extension

[Rocky Bernstein]

Please move this discussion elsewhere.

On Mon, Jul 31, 2017 at 8:40 AM, Thomas Schmitt <address@hidden> 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
>
>
>