[Top][All Lists]

[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


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
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
  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 :)


reply via email to

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