libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible


From: Thomas Schmitt
Subject: Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB
Date: Mon, 09 Jul 2018 12:54:09 +0200

Hi,

while copying Pete's work from example/isofile.c to example/C++/isofile.cpp
i noticed that the j-loop assumes full blocks in all but the last extent
of a data file.
All blocks get read and written fully. Only the last extent's copy gets
adjusted by ftruncate(3).

I did not notice this when working on the .c files in ./examples.
Pete, were you aware when you made your changes ?


Reasoning why this assumption is very inappropriate currently:

If we made it, then we would not need to model extents at all.
It would suffice to add to iso9660_stat_t a large integer as ".total_size"
and to deprecate the use of ".size".
Applications would not need to loop over extents but simply loop longer
over the blocks of a single giant extent.

The assumption itself is quite plausible. I do not know real ISO images
where it would not hold. For ISO producer software it is very natural.
But: It is not in the ISO 9660 specs and it is not in Linux kernel.

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

What does this mean for our current discussion ?

If we agree to make that assumption, then Pete's proposal can be reduced
to a form which is very convenient for the existing applications.
They would only have to change the use of one struct member.
(ABI would break anyway.)

If we do not agree to that assumption, then somebody will have to correct
the extent loops in his proposal.

The assumption makes few sense with my proposal. Either we can do it cheap
or we can do it right.
So i will now adapt the extent loops in ./example and ./test of my branch.
I will give you a note when the first loop is ready for review.

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

Further my proposal still needs two boss decisions, before it could
potentially be accepted:

* Give the type enmum of iso9660_stat_t a name ?
  Currently: No.
  Consequence: New API has to simulate anonymous enum values by integers.

* Where to declare semi-public methods of iso_rock_statbuf_t ?
  Currently: Declared in iso9660_fs.c and rock.c. Not in any header file.
  Consequence: Clumsy. That's what header files are for.


Have a nice day :)

Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]