Rutabaga backwards compatibility

[Alyssa Ross]

Gurchetan Singh <gurchet...@chromium.org> writes:

> On Mon, Jul 24, 2023 at 2:56 AM Alyssa Ross <h...@alyssa.is> wrote:
>>
>> Gurchetan Singh <gurchet...@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.

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)

[Gurchetan Singh]

On Tue, Aug 1, 2023 at 8:18 AM Alyssa Ross <h...@alyssa.is> wrote:

Gurchetan Singh <gurchet...@chromium.org> writes:

> On Mon, Jul 24, 2023 at 2:56 AM Alyssa Ross <h...@alyssa.is> wrote:
>>
>> Gurchetan Singh <gurchet...@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?

[Alyssa Ross]

Gurchetan Singh <gurchet...@chromium.org> writes:

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