On Tue, Aug 1, 2023 at 8:18 AM Alyssa Ross <h...@alyssa.is> wrote: > Gurchetan Singh <gurchetansi...@chromium.org> writes: > > > On Mon, Jul 24, 2023 at 2:56 AM Alyssa Ross <h...@alyssa.is> wrote: > >> > >> Gurchetan Singh <gurchetansi...@chromium.org> writes: > >> > >> > In terms of API stability/versioning/packaging, once this series is > >> > reviewed, the plan is to cut a "gfxstream upstream release branch". > We > >> > will have the same API guarantees as any other QEMU project then, i.e > no > >> > breaking API changes for 5 years. > >> > >> What about Rutabaga? > > > > Yes, rutabaga + gfxstream will both be versioned and maintain API > > backwards compatibility in line with QEMU guidelines. > > In that case, I should draw your attention to > <https://crrev.com/c/4584252>, which I've just realised while testing v2 > of your series here breaks the build of the rutabaga ffi, and which will > require the addition of a "prot" field to struct rutabaga_handle (a > breaking change). I'll push a new version of that CL to fix rutabaga > ffi in the next few days. >
Sorry, I didn't see this until now. At first glance, do we need to modify the rutabaga_handle? Can't we do fcntl(.., GET_FL) to get the access flags when needed? Since this is already coming up, before the release has even been made, > is it worth exploring how to limit the rutabaga API to avoid more > breaking changes after the release? Could there be more use of opaque > structs, for example? > > (CCing the crosvm list) >
