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

[Thomas Schmitt]

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