Gurchetan Singh <gurchetansi...@chromium.org> writes: > 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?
That was my original approach[1], but it was difficult to make work on Windows and not popular. [1]: https://crrev.com/c/4543310
signature.asc
Description: PGP signature
