From: Gurchetan Singh <gurchetansingh@google.com>

Changes since v10:
- Licensing and comment fixes

- Official "release commits" issued for rutabaga_gfx_ffi,
  gfxstream, aemu-base.  For example, see crrev.com/c/4778941

- The release commits can make packaging easier, though once
  again all known users will likely just build from sources
  anyways

How to build both rutabaga and gfxstream guest/host libs:

https://crosvm.dev/book/appendix/rutabaga_gfx.html

Branch containing this patch series:

https://gitlab.freedesktop.org/gurchetansingh/qemu-gfxstream/-/commits/qemu-gfxstream-v11

Antonio Caggiano (2):
  virtio-gpu: CONTEXT_INIT feature
  virtio-gpu: blob prep

Dr. David Alan Gilbert (1):
  virtio: Add shared memory capability

Gerd Hoffmann (1):
  virtio-gpu: hostmem

Gurchetan Singh (5):
  gfxstream + rutabaga prep: added need defintions, fields, and options
  gfxstream + rutabaga: add initial support for gfxstream
  gfxstream + rutabaga: meson support
  gfxstream + rutabaga: enable rutabaga
  docs/system: add basic virtio-gpu documentation

 docs/system/device-emulation.rst     |    1 +
 docs/system/devices/virtio-gpu.rst   |  112 +++
 hw/display/meson.build               |   22 +
 hw/display/virtio-gpu-base.c         |    6 +-
 hw/display/virtio-gpu-pci-rutabaga.c |   50 ++
 hw/display/virtio-gpu-pci.c          |   14 +
 hw/display/virtio-gpu-rutabaga.c     | 1121 ++++++++++++++++++++++++++
 hw/display/virtio-gpu.c              |   16 +-
 hw/display/virtio-vga-rutabaga.c     |   53 ++
 hw/display/virtio-vga.c              |   33 +-
 hw/virtio/virtio-pci.c               |   18 +
 include/hw/virtio/virtio-gpu-bswap.h |   18 +
 include/hw/virtio/virtio-gpu.h       |   41 +
 include/hw/virtio/virtio-pci.h       |    4 +
 meson.build                          |    7 +
 meson_options.txt                    |    2 +
 scripts/meson-buildoptions.sh        |    3 +
 softmmu/qdev-monitor.c               |    3 +
 softmmu/vl.c                         |    1 +
 19 files changed, 1506 insertions(+), 19 deletions(-)
 create mode 100644 docs/system/devices/virtio-gpu.rst
 create mode 100644 hw/display/virtio-gpu-pci-rutabaga.c
 create mode 100644 hw/display/virtio-gpu-rutabaga.c
 create mode 100644 hw/display/virtio-vga-rutabaga.c

-- 
2.42.0.rc1.204.g551eb34607-goog

Gurchetan Singh <gurchetansingh@chromium.org> writes:

> - Official "release commits" issued for rutabaga_gfx_ffi,
>   gfxstream, aemu-base.  For example, see crrev.com/c/4778941
>
> - The release commits can make packaging easier, though once
>   again all known users will likely just build from sources
>   anyways

It's a small thing, but could there be actual tags, rather than just
blessed commits?  It'd just make them easier to find, and save a bit of
time in review for packages.

On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote:

> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>
> > - Official "release commits" issued for rutabaga_gfx_ffi,
> >   gfxstream, aemu-base.  For example, see crrev.com/c/4778941
> >
> > - The release commits can make packaging easier, though once
> >   again all known users will likely just build from sources
> >   anyways
>
> It's a small thing, but could there be actual tags, rather than just
> blessed commits?  It'd just make them easier to find, and save a bit of
> time in review for packages.
>

I added:

https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging

Tags are possible, but I want to clarify the use case before packaging.
Where are you thinking of packaging it for (Debian??)? Are you mostly
interested in Wayland passthrough (my guess) or gfxstream too?  Depending
your use case, we may be able to minimize the work involved.

Gurchetan Singh <gurchetansingh@chromium.org> writes:

> On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote:
>
>> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>>
>> > - Official "release commits" issued for rutabaga_gfx_ffi,
>> >   gfxstream, aemu-base.  For example, see crrev.com/c/4778941
>> >
>> > - The release commits can make packaging easier, though once
>> >   again all known users will likely just build from sources
>> >   anyways
>>
>> It's a small thing, but could there be actual tags, rather than just
>> blessed commits?  It'd just make them easier to find, and save a bit of
>> time in review for packages.
>>
>
> I added:
>
> https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging
>
> Tags are possible, but I want to clarify the use case before packaging.
> Where are you thinking of packaging it for (Debian??)? Are you mostly
> interested in Wayland passthrough (my guess) or gfxstream too?  Depending
> your use case, we may be able to minimize the work involved.

Packaging for Nixpkgs (where I already maintain what to my knowledge is
the only crosvm distro package).  I'm personally mostly interested in
Wayland passthroug, but I wouldn't be surprised if others are interested
in gfxstream.  The packaging work is already done, I've just been
holding off actually pushing the packages waiting for the stable
releases.

The reason that tags would be useful is that it allows a reviewer of the
package to see at a glance that the package is built from a stable
release.  If it's just built from a commit hash, they have to go and
verify that it's a stable release, which is mildly annoying and
unconventional.

On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross <hi@alyssa.is> wrote:

> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>
> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote:
> >
> >> Gurchetan Singh <gurchetansingh@chromium.org> writes:
> >>
> >> > - Official "release commits" issued for rutabaga_gfx_ffi,
> >> >   gfxstream, aemu-base.  For example, see crrev.com/c/4778941
> >> >
> >> > - The release commits can make packaging easier, though once
> >> >   again all known users will likely just build from sources
> >> >   anyways
> >>
> >> It's a small thing, but could there be actual tags, rather than just
> >> blessed commits?  It'd just make them easier to find, and save a bit of
> >> time in review for packages.
> >>
> >
> > I added:
> >
> >
> https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging
> >
> > Tags are possible, but I want to clarify the use case before packaging.
> > Where are you thinking of packaging it for (Debian??)? Are you mostly
> > interested in Wayland passthrough (my guess) or gfxstream too?  Depending
> > your use case, we may be able to minimize the work involved.
>
> Packaging for Nixpkgs (where I already maintain what to my knowledge is
> the only crosvm distro package).  I'm personally mostly interested in
> Wayland passthroug, but I wouldn't be surprised if others are interested
> in gfxstream.  The packaging work is already done, I've just been
> holding off actually pushing the packages waiting for the stable
> releases.
>
> The reason that tags would be useful is that it allows a reviewer of the
> package to see at a glance that the package is built from a stable
> release.  If it's just built from a commit hash, they have to go and
> verify that it's a stable release, which is mildly annoying and
> unconventional.
>

Understood.  Request to have gfxstream and AEMU v0.1.2 release tags made.

For rutabaga_gfx_ffi, is the crates.io upload sufficient?

https://crates.io/crates/rutabaga_gfx_ffi

Debian, for example, treats crates.io as the source of truth and builds
tooling around that.  I wonder if Nixpkgs as similar tooling around
crates.io.

Gurchetan Singh <gurchetansingh@chromium.org> writes:

> On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross <hi@alyssa.is> wrote:
>
>> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>>
>> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote:
>> >
>> >> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>> >>
>> >> > - Official "release commits" issued for rutabaga_gfx_ffi,
>> >> >   gfxstream, aemu-base.  For example, see crrev.com/c/4778941
>> >> >
>> >> > - The release commits can make packaging easier, though once
>> >> >   again all known users will likely just build from sources
>> >> >   anyways
>> >>
>> >> It's a small thing, but could there be actual tags, rather than just
>> >> blessed commits?  It'd just make them easier to find, and save a bit of
>> >> time in review for packages.
>> >>
>> >
>> > I added:
>> >
>> >
>> https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging
>> >
>> > Tags are possible, but I want to clarify the use case before packaging.
>> > Where are you thinking of packaging it for (Debian??)? Are you mostly
>> > interested in Wayland passthrough (my guess) or gfxstream too?  Depending
>> > your use case, we may be able to minimize the work involved.
>>
>> Packaging for Nixpkgs (where I already maintain what to my knowledge is
>> the only crosvm distro package).  I'm personally mostly interested in
>> Wayland passthroug, but I wouldn't be surprised if others are interested
>> in gfxstream.  The packaging work is already done, I've just been
>> holding off actually pushing the packages waiting for the stable
>> releases.
>>
>> The reason that tags would be useful is that it allows a reviewer of the
>> package to see at a glance that the package is built from a stable
>> release.  If it's just built from a commit hash, they have to go and
>> verify that it's a stable release, which is mildly annoying and
>> unconventional.
>>
>
> Understood.  Request to have gfxstream and AEMU v0.1.2 release tags made.
>
> For rutabaga_gfx_ffi, is the crates.io upload sufficient?
>
> https://crates.io/crates/rutabaga_gfx_ffi
>
> Debian, for example, treats crates.io as the source of truth and builds
> tooling around that.  I wonder if Nixpkgs as similar tooling around
> crates.io.

We do, and I'll use the crates.io release for the package — good
suggestion, but it's still useful to also have a tag in a git repo.  It
makes it easier if I need to do a bisect, for example.  As a distro
developer, I'm frequently jumping across codebases I am not very
familiar with to try to track down regressions, etc., and it's much
easier when I don't have to learn some special quirk of the package like
not having git tags.

Alyssa Ross <hi@alyssa.is> writes:

> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>
>> On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross <hi@alyssa.is> wrote:
>>
>>> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>>>
>>> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote:
>>> >
>>> >> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>>> >>
>>> >> > - Official "release commits" issued for rutabaga_gfx_ffi,
>>> >> >   gfxstream, aemu-base.  For example, see crrev.com/c/4778941
>>> >> >
>>> >> > - The release commits can make packaging easier, though once
>>> >> >   again all known users will likely just build from sources
>>> >> >   anyways
>>> >>
>>> >> It's a small thing, but could there be actual tags, rather than just
>>> >> blessed commits?  It'd just make them easier to find, and save a bit of
>>> >> time in review for packages.
>>> >>
>>> >
>>> > I added:
>>> >
>>> >
>>> https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging
>>> >
>>> > Tags are possible, but I want to clarify the use case before packaging.
>>> > Where are you thinking of packaging it for (Debian??)? Are you mostly
>>> > interested in Wayland passthrough (my guess) or gfxstream too?  Depending
>>> > your use case, we may be able to minimize the work involved.
>>>
>>> Packaging for Nixpkgs (where I already maintain what to my knowledge is
>>> the only crosvm distro package).  I'm personally mostly interested in
>>> Wayland passthroug, but I wouldn't be surprised if others are interested
>>> in gfxstream.  The packaging work is already done, I've just been
>>> holding off actually pushing the packages waiting for the stable
>>> releases.
>>>
>>> The reason that tags would be useful is that it allows a reviewer of the
>>> package to see at a glance that the package is built from a stable
>>> release.  If it's just built from a commit hash, they have to go and
>>> verify that it's a stable release, which is mildly annoying and
>>> unconventional.
>>>
>>
>> Understood.  Request to have gfxstream and AEMU v0.1.2 release tags made.
>>
>> For rutabaga_gfx_ffi, is the crates.io upload sufficient?
>>
>> https://crates.io/crates/rutabaga_gfx_ffi
>>
>> Debian, for example, treats crates.io as the source of truth and builds
>> tooling around that.  I wonder if Nixpkgs as similar tooling around
>> crates.io.
>
> We do, and I'll use the crates.io release for the package — good
> suggestion, but it's still useful to also have a tag in a git repo.  It
> makes it easier if I need to do a bisect, for example.  As a distro
> developer, I'm frequently jumping across codebases I am not very
> familiar with to try to track down regressions, etc., and it's much
> easier when I don't have to learn some special quirk of the package like
> not having git tags.

Aha, trying to switch my package over to it has revealed that there is
actually a reason not to use the crates.io release.  It doesn't include
a Cargo.lock, which would mean we'd have to obtain one from elsewhere.
Either from the crosvm git repo, at which point we might just get all
the sources from there, or by vendoring a Cargo.lock into our own git
tree for packages, which we try to avoid because when you have a lot of
them, they become quite a large proportion of the overall size of the
repo.

(This probably differs from Debian, etc., because in Nixpkgs, we don't
package each crate dependency separately.  We only have packages for
applications (or occasionally, C ABI libraries written in Rust), and
each of those gets to bring in whatever crate dependencies it wants as
part of its build.  This means we use the upstream Cargo.lock, and
accept that different Rust packages will use lots of different versions
of dependencies, which I don't believe is the case with other distros
that take a more purist approach to Rust packaging.)

On Fri, Aug 25, 2023 at 12:37 PM Alyssa Ross <hi@alyssa.is> wrote:

> Alyssa Ross <hi@alyssa.is> writes:
>
> > Gurchetan Singh <gurchetansingh@chromium.org> writes:
> >
> >> On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross <hi@alyssa.is> wrote:
> >>
> >>> Gurchetan Singh <gurchetansingh@chromium.org> writes:
> >>>
> >>> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote:
> >>> >
> >>> >> Gurchetan Singh <gurchetansingh@chromium.org> writes:
> >>> >>
> >>> >> > - Official "release commits" issued for rutabaga_gfx_ffi,
> >>> >> >   gfxstream, aemu-base.  For example, see crrev.com/c/4778941
> >>> >> >
> >>> >> > - The release commits can make packaging easier, though once
> >>> >> >   again all known users will likely just build from sources
> >>> >> >   anyways
> >>> >>
> >>> >> It's a small thing, but could there be actual tags, rather than just
> >>> >> blessed commits?  It'd just make them easier to find, and save a
> bit of
> >>> >> time in review for packages.
> >>> >>
> >>> >
> >>> > I added:
> >>> >
> >>> >
> >>>
> https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging
> >>> >
> >>> > Tags are possible, but I want to clarify the use case before
> packaging.
> >>> > Where are you thinking of packaging it for (Debian??)? Are you mostly
> >>> > interested in Wayland passthrough (my guess) or gfxstream too?
> Depending
> >>> > your use case, we may be able to minimize the work involved.
> >>>
> >>> Packaging for Nixpkgs (where I already maintain what to my knowledge is
> >>> the only crosvm distro package).  I'm personally mostly interested in
> >>> Wayland passthroug, but I wouldn't be surprised if others are
> interested
> >>> in gfxstream.  The packaging work is already done, I've just been
> >>> holding off actually pushing the packages waiting for the stable
> >>> releases.
> >>>
> >>> The reason that tags would be useful is that it allows a reviewer of
> the
> >>> package to see at a glance that the package is built from a stable
> >>> release.  If it's just built from a commit hash, they have to go and
> >>> verify that it's a stable release, which is mildly annoying and
> >>> unconventional.
> >>>
> >>
> >> Understood.  Request to have gfxstream and AEMU v0.1.2 release tags
> made.
> >>
> >> For rutabaga_gfx_ffi, is the crates.io upload sufficient?
> >>
> >> https://crates.io/crates/rutabaga_gfx_ffi
> >>
> >> Debian, for example, treats crates.io as the source of truth and builds
> >> tooling around that.  I wonder if Nixpkgs as similar tooling around
> >> crates.io.
> >
> > We do, and I'll use the crates.io release for the package — good
> > suggestion, but it's still useful to also have a tag in a git repo.  It
> > makes it easier if I need to do a bisect, for example.  As a distro
> > developer, I'm frequently jumping across codebases I am not very
> > familiar with to try to track down regressions, etc., and it's much
> > easier when I don't have to learn some special quirk of the package like
> > not having git tags.
>
> Aha, trying to switch my package over to it has revealed that there is
> actually a reason not to use the crates.io release.  It doesn't include
> a Cargo.lock, which would mean we'd have to obtain one from elsewhere.
> Either from the crosvm git repo, at which point we might just get all
> the sources from there, or by vendoring a Cargo.lock into our own git
> tree for packages, which we try to avoid because when you have a lot of
> them, they become quite a large proportion of the overall size of the
> repo.
>

Ack.  Request to have a rutabaga release tag in crosvm also made, should be
complete in a few days.


>
> (This probably differs from Debian, etc., because in Nixpkgs, we don't
> package each crate dependency separately.  We only have packages for
> applications (or occasionally, C ABI libraries written in Rust), and
> each of those gets to bring in whatever crate dependencies it wants as
> part of its build.  This means we use the upstream Cargo.lock, and
> accept that different Rust packages will use lots of different versions
> of dependencies, which I don't believe is the case with other distros
> that take a more purist approach to Rust packaging.)
>

Gurchetan Singh <gurchetansingh@chromium.org> writes:

> On Fri, Aug 25, 2023 at 12:37 PM Alyssa Ross <hi@alyssa.is> wrote:
>
>> Alyssa Ross <hi@alyssa.is> writes:
>>
>> > Gurchetan Singh <gurchetansingh@chromium.org> writes:
>> >
>> >> On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross <hi@alyssa.is> wrote:
>> >>
>> >>> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>> >>>
>> >>> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote:
>> >>> >
>> >>> >> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>> >>> >>
>> >>> >> > - Official "release commits" issued for rutabaga_gfx_ffi,
>> >>> >> >   gfxstream, aemu-base.  For example, see crrev.com/c/4778941
>> >>> >> >
>> >>> >> > - The release commits can make packaging easier, though once
>> >>> >> >   again all known users will likely just build from sources
>> >>> >> >   anyways
>> >>> >>
>> >>> >> It's a small thing, but could there be actual tags, rather than just
>> >>> >> blessed commits?  It'd just make them easier to find, and save a
>> bit of
>> >>> >> time in review for packages.
>> >>> >>
>> >>> >
>> >>> > I added:
>> >>> >
>> >>> >
>> >>>
>> https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging
>> >>> >
>> >>> > Tags are possible, but I want to clarify the use case before
>> packaging.
>> >>> > Where are you thinking of packaging it for (Debian??)? Are you mostly
>> >>> > interested in Wayland passthrough (my guess) or gfxstream too?
>> Depending
>> >>> > your use case, we may be able to minimize the work involved.
>> >>>
>> >>> Packaging for Nixpkgs (where I already maintain what to my knowledge is
>> >>> the only crosvm distro package).  I'm personally mostly interested in
>> >>> Wayland passthroug, but I wouldn't be surprised if others are
>> interested
>> >>> in gfxstream.  The packaging work is already done, I've just been
>> >>> holding off actually pushing the packages waiting for the stable
>> >>> releases.
>> >>>
>> >>> The reason that tags would be useful is that it allows a reviewer of
>> the
>> >>> package to see at a glance that the package is built from a stable
>> >>> release.  If it's just built from a commit hash, they have to go and
>> >>> verify that it's a stable release, which is mildly annoying and
>> >>> unconventional.
>> >>>
>> >>
>> >> Understood.  Request to have gfxstream and AEMU v0.1.2 release tags
>> made.
>> >>
>> >> For rutabaga_gfx_ffi, is the crates.io upload sufficient?
>> >>
>> >> https://crates.io/crates/rutabaga_gfx_ffi
>> >>
>> >> Debian, for example, treats crates.io as the source of truth and builds
>> >> tooling around that.  I wonder if Nixpkgs as similar tooling around
>> >> crates.io.
>> >
>> > We do, and I'll use the crates.io release for the package — good
>> > suggestion, but it's still useful to also have a tag in a git repo.  It
>> > makes it easier if I need to do a bisect, for example.  As a distro
>> > developer, I'm frequently jumping across codebases I am not very
>> > familiar with to try to track down regressions, etc., and it's much
>> > easier when I don't have to learn some special quirk of the package like
>> > not having git tags.
>>
>> Aha, trying to switch my package over to it has revealed that there is
>> actually a reason not to use the crates.io release.  It doesn't include
>> a Cargo.lock, which would mean we'd have to obtain one from elsewhere.
>> Either from the crosvm git repo, at which point we might just get all
>> the sources from there, or by vendoring a Cargo.lock into our own git
>> tree for packages, which we try to avoid because when you have a lot of
>> them, they become quite a large proportion of the overall size of the
>> repo.
>>
>
> Ack.  Request to have a rutabaga release tag in crosvm also made, should be
> complete in a few days.

Thanks!  I've found the rutabaga tag, but I still don't see any relevant
tags for aemu or gfxstream.  Any news there?

On Tue, Sep 12, 2023 at 1:53 AM Alyssa Ross <hi@alyssa.is> wrote:

> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>
> > On Fri, Aug 25, 2023 at 12:37 PM Alyssa Ross <hi@alyssa.is> wrote:
> >
> >> Alyssa Ross <hi@alyssa.is> writes:
> >>
> >> > Gurchetan Singh <gurchetansingh@chromium.org> writes:
> >> >
> >> >> On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross <hi@alyssa.is> wrote:
> >> >>
> >> >>> Gurchetan Singh <gurchetansingh@chromium.org> writes:
> >> >>>
> >> >>> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote:
> >> >>> >
> >> >>> >> Gurchetan Singh <gurchetansingh@chromium.org> writes:
> >> >>> >>
> >> >>> >> > - Official "release commits" issued for rutabaga_gfx_ffi,
> >> >>> >> >   gfxstream, aemu-base.  For example, see crrev.com/c/4778941
> >> >>> >> >
> >> >>> >> > - The release commits can make packaging easier, though once
> >> >>> >> >   again all known users will likely just build from sources
> >> >>> >> >   anyways
> >> >>> >>
> >> >>> >> It's a small thing, but could there be actual tags, rather than
> just
> >> >>> >> blessed commits?  It'd just make them easier to find, and save a
> >> bit of
> >> >>> >> time in review for packages.
> >> >>> >>
> >> >>> >
> >> >>> > I added:
> >> >>> >
> >> >>> >
> >> >>>
> >>
> https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging
> >> >>> >
> >> >>> > Tags are possible, but I want to clarify the use case before
> >> packaging.
> >> >>> > Where are you thinking of packaging it for (Debian??)? Are you
> mostly
> >> >>> > interested in Wayland passthrough (my guess) or gfxstream too?
> >> Depending
> >> >>> > your use case, we may be able to minimize the work involved.
> >> >>>
> >> >>> Packaging for Nixpkgs (where I already maintain what to my
> knowledge is
> >> >>> the only crosvm distro package).  I'm personally mostly interested
> in
> >> >>> Wayland passthroug, but I wouldn't be surprised if others are
> >> interested
> >> >>> in gfxstream.  The packaging work is already done, I've just been
> >> >>> holding off actually pushing the packages waiting for the stable
> >> >>> releases.
> >> >>>
> >> >>> The reason that tags would be useful is that it allows a reviewer of
> >> the
> >> >>> package to see at a glance that the package is built from a stable
> >> >>> release.  If it's just built from a commit hash, they have to go and
> >> >>> verify that it's a stable release, which is mildly annoying and
> >> >>> unconventional.
> >> >>>
> >> >>
> >> >> Understood.  Request to have gfxstream and AEMU v0.1.2 release tags
> >> made.
> >> >>
> >> >> For rutabaga_gfx_ffi, is the crates.io upload sufficient?
> >> >>
> >> >> https://crates.io/crates/rutabaga_gfx_ffi
> >> >>
> >> >> Debian, for example, treats crates.io as the source of truth and
> builds
> >> >> tooling around that.  I wonder if Nixpkgs as similar tooling around
> >> >> crates.io.
> >> >
> >> > We do, and I'll use the crates.io release for the package — good
> >> > suggestion, but it's still useful to also have a tag in a git repo.
> It
> >> > makes it easier if I need to do a bisect, for example.  As a distro
> >> > developer, I'm frequently jumping across codebases I am not very
> >> > familiar with to try to track down regressions, etc., and it's much
> >> > easier when I don't have to learn some special quirk of the package
> like
> >> > not having git tags.
> >>
> >> Aha, trying to switch my package over to it has revealed that there is
> >> actually a reason not to use the crates.io release.  It doesn't include
> >> a Cargo.lock, which would mean we'd have to obtain one from elsewhere.
> >> Either from the crosvm git repo, at which point we might just get all
> >> the sources from there, or by vendoring a Cargo.lock into our own git
> >> tree for packages, which we try to avoid because when you have a lot of
> >> them, they become quite a large proportion of the overall size of the
> >> repo.
> >>
> >
> > Ack.  Request to have a rutabaga release tag in crosvm also made, should
> be
> > complete in a few days.
>
> Thanks!  I've found the rutabaga tag, but I still don't see any relevant
> tags for aemu or gfxstream.  Any news there?
>

It's harder to get the attention of the Android build team than the Chrome
build team.  Though, there are a few issues with AEMU/gfxstream packaging
we also need to figure out -- see "[PATCH v13 0/9] rutabaga_gfx +
gfxstream" for details -- interested in your opinion on the matter!

Gurchetan Singh <gurchetansingh@chromium.org> writes:

> It's harder to get the attention of the Android build team than the Chrome
> build team.  Though, there are a few issues with AEMU/gfxstream packaging
> we also need to figure out -- see "[PATCH v13 0/9] rutabaga_gfx +
> gfxstream" for details -- interested in your opinion on the matter!

None of the other points there are issues for me — in Nixpkgs, every
package is installed to a unique prefix (different versions of the same
package, or even just different build recipes for the same version, or
different dependencies result in different prefixes), so library
versioning and the /usr/include directories are not blockers.  Static
libraries are also fine for Nixpkgs — any change to a library, static or
dynamic, causes all dependents to be rebuild against the new library, so
the only real disadvantage to static libraries is the duplication on
disk, which isn't a big deal.

All that's to say, I'm ready to have rutabaga support, including
gfxstream, in our QEMU package, as soon as a release of QEMU including
it is made.  Everything Marc-André has identified would still be nice to
have fixed, but for us specifically, none of it is a blocker, even the
tags I asked for.