Re: Rutabaga backwards compatibility

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]

Gurchetan Singh <gurchetansingh@chromium.org> writes:

> On Tue, Aug 1, 2023 at 8:18 AM Alyssa Ross <hi@alyssa.is> wrote:
>
>> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>>
>> > On Mon, Jul 24, 2023 at 2:56 AM Alyssa Ross <hi@alyssa.is> wrote:
>> >>
>> >> Gurchetan Singh <gurchetansingh@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]