libcdio-devel
[Top][All Lists]
Advanced

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

[Libcdio-devel] ABI problem with: [PATCH v2] add multi extent ISO9660 fi


From: Thomas Schmitt
Subject: [Libcdio-devel] ABI problem with: [PATCH v2] add multi extent ISO9660 file support to libcdio
Date: Wed, 27 Jun 2018 20:35:23 +0200

Hi,

i wrote:
> > Currently i am not sure whether an API extension would be that much more
> > development work

Pete Batard wrote:
> In that case, I'm going to respectfully ask someone else to do that work,
> because I have spent about as much time as I can allocate to adding
> multi-extent support to mainline libcdio.

Well, instead of committing ritual suicide because of
  
https://www.nytimes.com/2018/06/27/sports/world-cup/germany-vs-south-korea.html
i might give it a try.

My plan is to:

- Switch to branch pbatard-multiextent2.
  Create a new branch ts-multiextent in the hope to inherit Pete's work.

- Change iso9660_stat_s.extent_lsn and iso9660_stat_s.extent_size
  to dynamically allocated memory (with proper destruction).

  Commit for a still ABI incompatible state with less memory waste.

- Rename existing mixed API function implementations iso9660_*_stat*() to
  new names iso9660_*_statv2*().
  Derive iso9660_statv2_s from iso9660_stat_s + DO_NOT_WANT_COMPATIBILITY.
  Remove multi-extent stuff from iso9660_stat_s.
  Implement old API functions again as mere frontends to the renamed
  functions.
  Expose iso9660_*_statv2*() calls which hand out iso9660_statv2_s.
  Implement and expose access functions for members of iso9660_statv2_s.
  
  Commit for ABI compatible state.

Does this sound reasonable ? Especially the first step with git wizzardry ?


Have a nice day :)

Thomas




reply via email to

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