Created attachment 251664 [details] [review]
core: Add API to convert checksum -> csum in place

We already have the opposite, and this will be used in some
places to avoid a malloc.

Created attachment 251665 [details] [review]
repo: Add API to load any object as a stream

We have APIs to load metadata as variants, and files as parsed
content/info/xattrs, but for some cases such as static deltas, all we
want is to operate on all objects in their canonical representation.

Created attachment 251666 [details] [review]
libotutil: Add API to create an "ay" GVariant from GBytes

We used to have a version of this, but since I'm trying to use
GBytes more, this became a more common operation, and it's annoying
to type out the whole G_VARIANT_TYPE ("ay") each time, and pass
TRUE for trusted.

Review of attachment 251666 [details] [review]:

OK.

Review of attachment 251664 [details] [review]:

::: src/libostree/ostree-core.c
@@ +1017,3 @@
+                                  guchar     *buf)
+{
+  checksum_to_bytes (checksum, buf);

Do you not just want to replace checksum_to_bytes and make ostree_checksum_to_bytes call the public function?

Review of attachment 251665 [details] [review]:

::: src/libostree/ostree-repo.c
@@ +2183,3 @@
+
+      if (!ostree_repo_load_variant (self, objtype, checksum, &metadata, error))
+        goto out;

Hm, given that the common case is that this generates a GVariant from a GMappedFile, it's a bit silly to read out the mmap contents and then stick it all in a GMemoryInputStream. Could you add something in ostree_repo_load_variant that somehow checks if the variant comes from a GMappedFile and then just create the GMappedFileInputStream from it?

Perhaps with some sneaky underhanded gdatalist shenanigans?

Created attachment 251669 [details] [review]
fileutils: Add API to fstat() a stream

Will be used by ostree.  Since libgsystem will return raw
GUnix{Input,Output}Stream, we need a way to fstat() them.  Maybe we
should also have an API to synthesize a #GFileInfo, but that's hard
without duplicating all the complex stuff in GIO.

Created attachment 251670 [details] [review]
core: Add API to convert checksum -> csum in place

We already have the opposite, and this will be used in some
places to avoid a malloc.

Created attachment 251671 [details] [review]
libotutil: Make use of GBytes in ot_variant_read()

This is just cleaner; we avoid using GObject data, etc.

Created attachment 251672 [details] [review]
repo: Add API to load any object as a stream

Although before we never actually *copied* data, it was mildly lame to
have a chain of mmap -> GMemoryInputStream, when we can just as easily
do a normal open() -> read() chain.

Review of attachment 251670 [details] [review]:

OK.

Review of attachment 251671 [details] [review]:

OK.

Did you forget to attach the patch that modifies ostree_variant_read?

Did you forget to attach the patch that modifies ostree_variant_read?

(In reply to comment #14)
> Did you forget to attach the patch that modifies ostree_variant_read?

There's one in comment #9 but note we weren't actually copying data before either.  g_memory_input_stream_new_from_data() doesn't copy.

(In reply to comment #14)
> Did you forget to attach the patch that modifies ostree_variant_read?

There's one in comment #9 but note we weren't actually copying data before either.  g_memory_input_stream_new_from_data() doesn't copy.

(In reply to comment #16)
> (In reply to comment #14)
> > Did you forget to attach the patch that modifies ostree_variant_read?
> 
> There's one in comment #9 but note we weren't actually copying data before
> either.  g_memory_input_stream_new_from_data() doesn't copy.

Ah, right, I forgot that GMappedFile isn't actually a GFile that we can g_file_read.

Review of attachment 251669 [details] [review]:

OK.

Review of attachment 251672 [details] [review]:

OK.

Attachment 251670 [details] pushed as d9f59c6 - core: Add API to convert checksum -> csum in place
Attachment 251671 [details] pushed as c77908b - libotutil: Make use of GBytes in ot_variant_read()

Created attachment 251677 [details] [review]
repo: Add API to load any object as a stream

Oops, I forgot to amend the last commit, that may have been what was
confusing you...this has the cleaner code.

Review of attachment 251677 [details] [review]:

This is indeed a lot better; thanks.

Attachment 251677 [details] pushed as 11bdbe1 - repo: Add API to load any object as a stream