[Libguestfs] [nbdkit PATCH 1/2] rust: Implement can_cache

[Martin Kletzander]

On Fri, Aug 16, 2019 at 08:15:28PM +0100, Richard W.M. Jones wrote:
>On Fri, Aug 16, 2019 at 01:05:58PM -0500, Eric Blake wrote:
>> On 8/16/19 1:01 PM, Eric Blake wrote:
>> > On 8/16/19 12:08 PM, Eric Blake wrote:
>> >> Implementing extents requires some coordination for the Rust code to
>> >> call back into libnbdkit; I'm not familiar with Rust enough to do
>> >> that. But with placeholders for those slots, implementing
>> >> can_cache/cache is trivial.  This improves the situation mentioned in
>> >> commit 031fae85.
>> >>
>> >> Signed-off-by: Eric Blake <eblake at redhat.com>
>> >> ---
>>
>> > And of course, if you want to actually implement extents, and figure out
>> > how to expose C-based nbdkit functions to be called by Rust code, be my
>> > guest (for .zero, we need nbdkit_set_error(), for extents, we need
>> > nbdkit_add_extent(), and then we have several other utility functions
>> > like nbdkit_realpath() that could be useful).
>>
>> Also, we are lacking a tests/*rust* usage; it would be nice if 'make
>> check' covered a Rust plugin (more than just running 'nbdkit
>> plugins/rust/target/release/examples/libramdisk.so').
>
>We certainly do need tests for the Rust plugin.  Actually placing them
>in tests/ might be difficult because Rust assumes a build environment
>(called cargo) and that requires a bunch of files.
>
>Since we already have cargo files it's probably better to put the
>tests for this plugin next to the plugin.  Unfortunately an additional
>complication is that we probably can't use the tests facility of cargo
>because we need to go through building a shared library and running it
>under the nbdkit wrapper.  Perhaps we can add them as further examples
>and wire up 'make check' to run them?  It's not especially elegant but
>here we are.
>

The terrible part is mixing cargo with autotools.  For me the biggest pain point
was making sure don't touch the source directory when building from a tarball.
Good thing is that you ship (as part of the tarball) all that is needed, because
it is a standalone "project", so it should be fine.

What would be the problem of make check building the plugin (usually it depends on `all` anyway, no?) and then just running it under the wrapper with $(top_builddir)/plugins/rust/target/release/... ?

Patches look fine.

Have a nice day,
Martin

>Rich.
>
>-- 
>Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>Read my programming and virtualization blog: http://rwmj.wordpress.com
>virt-top is 'top' for virtual machines.  Tiny program with many
>powerful monitoring features, net stats, disk stats, logging, etc.
>http://people.redhat.com/~rjones/virt-top
>
>_______________________________________________
>Libguestfs mailing list
>Libguestfs at redhat.com
>https://www.redhat.com/mailman/listinfo/libguestfs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190820/d1e50e12/attachment.sig>