Syslinux - Mar 2013 - Rock Ridge for core/fs/iso9660

Hi,

i have now a retriever of Rock Ridge names from ISO directory
records and their eventual Continuation Areas.
Further i have a detector for SUSP and Rock Ridge signatures.

Both have been tested in libisofs by comparing their results with
the Rock Ridge info as perceived by the library.
50 ISO images tested.  Some bugs repaired. Now they are in sync.
(The macro case Isolinux_rockridge_in_libisofS in susp_rr.c can
 later be removed, when no further tests in libisofs are expected.)

Most of the code is in two new source files:
  core/fs/iso9660/susp_rr.h  ~  4000 bytes
  core/fs/iso9660/susp_rr.c  ~ 15000 bytes
Opinions regarding coding style and license are welcome.


I inserted two calls of susp_rr_get_nm() into iso9660/iso9660.c,
so that hopefully Rock Ridge names will be processed in functions
iso_find_entry() and iso_readdir(). The old ISO name processing
is supposed to still work as fallback.

Function iso_fs_init() now ends by a call of the Rock Ridge
detector susp_rr_check_signatures().

struct iso_sb_info in iso9660_fs.h has been extended by a flag,
whether Rock Ridge is enabled, and by a skip length variable.
The latter has not been tested with non-zero values, because i
actually never saw an ISO image with such a skip length.
(Maybe it has something to do with ISO 9660 on CD-ROM XA.
 Normal runs of cdrecord or libburn produce CD-ROM Mode1.)


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

This all compiles now in syslinux from git on a Debian 6 system.
It has no "upx" and apt-file search does not find any. At the end
there are complaints by ls about missing win32/syslinux.exe and
win64/syslinux64.exe.
But the run ends by a long list of files and
  make: [all] Error 2 (ignored)
No errors are reported when compiling iso9660.c and susp_rr.c.

The code changes in iso9660.c have not been tested further, though.

Attached is a file iso9660.diff for the two already existing files
and a tarball iso9660_susp_rr.tar.gz with all four affected files:
  iso9660/iso9660.c
  iso9660/iso9660_fs.h
  iso9660/susp_rr.c
  iso9660/susp_rr.h
I added the two existing files to the tarball just in case that
my diff is inconvenient.


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

Interesting test images should have very long Rock Ridge names with
files that matter for boot success. This will exercise CE entries.
Further: Mixed case file names which would collide if transformed
to lower case.

One should try with images which have no Rock Ridge, old Rock Ridge
1.10 (mkisofs, xorriso default), and new Rock Ridge 1.12
(xorriso -compliance new_rr ...), and images from non-Linux sources
(I tried an original Microsoft DVD "TECHNET_TOOLBOX" which i got
 with a print copy of german Linux Magazin. No Rock Ridge on it.)


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

I wonder whether the Linux kernel does not demand a Rock Ridge ER.
At least i cannot spot a refusal to interpret Rock Ridge if it
is missing. I cannot even spot the Rock Ridge id texts "RRIP_1991A",
"IEEE_P1282", and "IEEE_1282".
(FreeBSD has such a test, as i learned a few years ago.)


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

I noticed another possible application for Rock Ridge:
    dirent->d_type = get_inode_mode(de->flags);
and
    inode->mode   = get_inode_mode(de->flags);
One could feed both with better info from Rock Ridge entry PX.

I understand that currently file types other than directory and
regular file show up as (empty) regular files.

Does syslinux have use for socket files, symbolic links,
block devices, character devices, or named pipes ?

Is there use for user id, group id, access permissions ?
(I do not see struct stat in iso9660.c)


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

Have a nice day :)

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iso9660.diff
Type: text/x-patch
Size: 3370 bytes
Desc: not available
URL:
<http://www.zytor.com/pipermail/syslinux/attachments/20130331/2a5af2ad/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iso9660_susp_rr.tar.gz
Type: application/x-tar
Size: 9066 bytes
Desc: not available
URL:
<http://www.zytor.com/pipermail/syslinux/attachments/20130331/2a5af2ad/attachment.tar>

On 03/31/2013 03:49 AM, scdbackup at gmx.net wrote:
> Hi,
> 
> i have now a retriever of Rock Ridge names from ISO directory
> records and their eventual Continuation Areas.
> Further i have a detector for SUSP and Rock Ridge signatures.
> 
> Both have been tested in libisofs by comparing their results with
> the Rock Ridge info as perceived by the library.
> 50 ISO images tested.  Some bugs repaired. Now they are in sync.
> (The macro case Isolinux_rockridge_in_libisofS in susp_rr.c can
>  later be removed, when no further tests in libisofs are expected.)
> 
> Most of the code is in two new source files:
>   core/fs/iso9660/susp_rr.h  ~  4000 bytes
>   core/fs/iso9660/susp_rr.c  ~ 15000 bytes
> Opinions regarding coding style and license are welcome.
> 
GPL v2+ is fine, as long as it is clearly understood (as part of
Syslinux in general) that Syslinux modules that communicate through the
exported entry points are not derivative and are not required to be GPL.

We tend to prefer Linux multiline comment style which looks like:

/*
 * Foo
 */

... rather than ...

/* Foo
 */

... but that is a minor issue which can be fixed later.
> 
> This all compiles now in syslinux from git on a Debian 6 system.
> It has no "upx" and apt-file search does not find any. At the end
> there are complaints by ls about missing win32/syslinux.exe and
> win64/syslinux64.exe.
> But the run ends by a long list of files and
>   make: [all] Error 2 (ignored)
> No errors are reported when compiling iso9660.c and susp_rr.c.
> 
Right.  All that happened was that the DOS and Windows utilities didn't
get made due to lack of compiler on your system.  No problem.
> I wonder whether the Linux kernel does not demand a Rock Ridge ER.
> At least i cannot spot a refusal to interpret Rock Ridge if it
> is missing. I cannot even spot the Rock Ridge id texts
"RRIP_1991A",
> "IEEE_P1282", and "IEEE_1282".
> (FreeBSD has such a test, as i learned a few years ago.)
Doesn't look like it.
> I understand that currently file types other than directory and
> regular file show up as (empty) regular files.
They can be made to show up in readdir() with the appropriate type;
Syslinux itself will not use them.
> Does syslinux have use for socket files, symbolic links,
> block devices, character devices, or named pipes ?
No.
> Is there use for user id, group id, access permissions ?
> (I do not see struct stat in iso9660.c)
No.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.