Re: API/ABI rank of headers in /usr/include/isofs/cd9660

["Thomas Schmitt" <scdbackup%gmx.net@localhost>]

Hi,

after learning the dire truth about includers of cd9660_node.h i am
pondering about ABI compatibility measures for the necessary
change which shall handle large files.

Alternative 1:
  Keep the old members and add some new members to the end of iso_node.
  Let the old members represent the first file section of the file.
  This is supposed to be absolutely API/ABI-safe for files with a single
  file section. (All other files are currently heavily misrepresented.
  Breaking their compatibility is not a real damage.)
  This alternative will at least waste 8 bytes per iso_node.

Alternative 2:
  Introduce a new struct iso_file_section with the same layout as the
  struct iso_node interval with the old members. Replace the old members
  by a union of struct iso_file_section and pointer to that struct.
  This breaks the API, but is supposed to be ABI-safe for machines with
  pointer size of up to 96 bits.
  It will waste at least 4 bytes per additional file section, which in
  normal ISO filesystem is supposed to happen very rarely.

I am currently working with alternative 2.
But if there is consensus to allow the storage waste of alternative 1,
then i could easily switch.

Please decide.

-------------------------------------------------------------------
Necessities:

In cd9660_node.h : struct iso_node, i plan to replace

        unsigned long iso_extent;
        unsigned long i_size;
        unsigned long iso_start;

effectively by

        union iso_file_data iso_fsect;

which is minimally definded as

        struct iso_file_section {
                uint32_t isofsc_start;  /* block address */
                uint32_t isofsc_size;   /* byte count */
        };
        union iso_file_data {
                struct iso_file_section single;
                struct iso_file_section *many;
        };

This will allow to avoid malloc(9) with the vast majority of
iso_node objects, unless the ISO is very exotic or even malicious.

------------------------------------------------------------------
Alternative 1:

+ struct iso_file_section {
+       uint32_t isofsc_start;  /* block address */
+       uint32_t isofsc_size;   /* byte count */
+ };
+ union iso_file_data {
+       struct iso_file_section single;
+       struct iso_file_section *many;
+ };
  struct iso_node {
        ...
        unsigned long iso_extent;
        unsigned long i_size;
        unsigned long iso_start;
        ...
+       union iso_file_data iso_fsect;  /* File sections. Their number is given
+                                        * by CD9660_FSECT_FROM_INO(.i_number)
+                                        */
 };

------------------------------------------------------------------
Alternative 2:

+ struct iso_file_section {
+       unsigned long isofsc_extent;    /* will not be used by cd9660 */
+       unsigned long isofsc_size;      /* byte count */
+       unsigned long isofsc_start;     /* block address */
+ };
+ union iso_file_data {
+       struct iso_file_section single;
+       struct iso_file_section *many;
+ };
  struct iso_node {
        ...
-       unsigned long iso_extent;
-       unsigned long i_size;
-       unsigned long iso_start;
+       union iso_file_data iso_fsect;  /* File sections. Their number is given
+                                        * by CD9660_FSECT_FROM_INO(.i_number)
+                                        */
        ...
 };

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

Have a nice day :)

Thomas