[syslinux] Rock Ridge

[Thomas Schmitt]

Hi,

> Stupid question: what do these limitations mean in practice?

Now you triggered a lengthy answer. :))

Also want to take the opportunity to warn of case-sensitivity.


> +   (XXX): Avoid memcpy() with Continuation Areas

This is some waste of computing time, because i did not make
the iterator smart enough to do its job without copying data
under certain circumstances. Those circumstances are quite rare.

The problem is that get_cache() does not guarantee that two
blocks with adjacent LBA will be held as adjacent copies in
the cache. So i allocate memory and copy the single blocks
in order to get them as one contiguous memory area.

This happens only if more than one block is involved by a CE entry.
CE is rare execept for the root directory records "." and "..",
which host the fat Rock Ridge ER entries.
Even if CE announces a Continuation Area, this often fits into a
single block.

You need about 220 characters in a file name to surely provoke
the production of CE entries for normal directory records.

Adding fat AAIP info by libisofs has the same effect. I.e. if a
file on Linux has lots of Extended Attributes or a long ACL.
  http://libburnia-project.org/wiki/AAIP
  xorriso -as mkisofs --xattr --acl ...


> +   (XXX): Take into respect ES entries ? (Hardly anybody does this.)

ES entries distinguish different SUSP extensions like Rock Ridge
or my AAIP.
They are necessary only if two such extensions use the same
entry signatures with different meaning. E.g. if both have
an NM entry.
There are not many SUSP extensions around. Those of which i
know (Rock Ridge, zisofs, Apple, Amiga, AAIP) do not collide by
entry signatures.
Linux seems to ignore ES. It does not appear in its isofs/rock.c.
libisofs produces ES if SUSP/RRIP 1.12 is selected. Default is
1.10 without ES.


-----------------------------------------------------------------

In both (XXX) cases i doubt that it is worthwile to invest complexity.
The benefit is sparse and the risk of bugs increases.


-----------------------------------------------------------------

What about this one:

XXX: Is there already a reader for 32-bit MSB or LSB in the syslinux code ?
     (iso9660.c seems to flatly assume that it runs on little-endian int.)

I re-invented byte-to-word translation in susp_rr.c.
iso9660.c had no such gesture as example. It rather picks the
little-endian byte strings of the 32-bit numbers from the ISO
and uses them directly as integers.

I understand syslinux is x86-only.
Nevertheless, my hairs are raised when i see that gesture.
One could replace all calls of susp_rr_read_msb() by the direct
use of the bytes which are four byte positions before the
big-endian byte strings wich i submit to susp_rr_read_msb().
E.g.:
        iter->next_lba = susp_rr_read_msb(u_entry + 8, 4);
to
        iter->next_lba = *((block_t *) u_entry + 4);

But as it is now, susp_rr.c should be easily portable to big-endian
processors.


-----------------------------------------------------------------

I see you commited the code.
This will make the file names in Rock Ridge enhanced ISO images
case-sensitive.

E.g. Apple HFS is addicted to case-insensitivity because the
users learned not to care for uppercase or lowercase.
Is it possible that the syslinux community already suffers from
a similar addiction to case-less ISO 9660 ?

Is there the need for an option that disables Rock Ridge
interpretation ? (Like with mount -o norock)


-----------------------------------------------------------------

Have a nice day :)

Thomas