<div dir="ltr"><div><br></div>I fixed this patch based on comments. I merged all commits to a single commit. I'll send this final patch to this list.<div><br></div><div>Regards,</div><div>Hiroyuki</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2019年7月8日(月) 19:36 Martin Kletzander <<a href="mailto:mkletzan@redhat.com">mkletzan@redhat.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jul 08, 2019 at 10:04:57AM +0100, Richard W.M. Jones wrote:<br>
>On Mon, Jul 08, 2019 at 10:49:55AM +0200, Martin Kletzander wrote:<br>
>> On Mon, Jul 08, 2019 at 10:10:10AM +0200, Pino Toscano wrote:<br>
>> >On Saturday, 6 July 2019 13:03:24 CEST Martin Kletzander wrote:<br>
>> >>Just one thing, the Cargo.toml includes a version under which the crate would be<br>
>> >>published.  I presume the version would be the same as the one of the project<br>
>> >>itself, i.e. when releasing libguestfs-x.y.z, we publish guestfs-rs-x.y.z to<br>
>> >><a href="http://crates.io" rel="noreferrer" target="_blank">crates.io</a>.<br>
>> ><br>
>> >Speaking of naming: it seems like libraries that interface/wrap a<br>
>> >foreign C/C++/etc library are usually called foo-sys -- so should our<br>
>> >binding be named guestfs-sys?<br>
>> ><br>
>><br>
>> So you've seen my RFC? =)<br>
>><br>
>> Just to guestfs-sys would be a crate that does only two things:<br>
>><br>
>> 1) exposes the C functions using `extern`<br>
>><br>
>> 2) links to the library<br>
>><br>
>> And then another crate (e.g. guestfs) would expose the higher-level, safe,<br>
>> hopefully idiomatic API.  More information (reasoning etc.) see:<br>
>><br>
>>  <a href="https://doc.rust-lang.org/cargo/reference/build-scripts.html#a-sys-packages" rel="noreferrer" target="_blank">https://doc.rust-lang.org/cargo/reference/build-scripts.html#a-sys-packages</a><br>
><br>
>For the Python guestfs bindings we originally planned to write an<br>
>idiomatic (ie. OO in that case) API on top of the raw generated<br>
>bindings, but never really got around to it.  I'm not convinced it's<br>
>really a good idea because you end up chasing new APIs.  Remember the<br>
>whole point of the generator is that new APIs are instantly available<br>
>in all languages as soon as they are added upstream.<br>
><br>
<br>
For the libnbd use-case I went with a middle ground.  That is libnbd-sys is a<br>
crated with just the linkage and list of extern functions, but libnbd is<br>
supposed to just expose this as methods on the Nbd struct, which take Rust types<br>
(as opposed to C types), ensure safety and idiomatically handle errors.<br>
<br>
No other extra redesign would be there, the code handles functions that are not<br>
allowed in a particular state nicely, so that should be fine.  The only thing<br>
what would be really nice to utilize in libnbd rust crate is the fact that the<br>
states there can be encoded into the way the structs are used, so that you could<br>
only call those APIs that are accessible at a current state (if that state is<br>
controllable by the client, of course), so for example you could use the builder<br>
pattern to create a handle prepared to be connected (or even connect it):<br>
<br>
  let h = Nbd::new()<br>
              .add_meta_context("base:allocation")<br>
              .set.export_name("/")<br>
              .set_debug(true)<br>
              .connect_uri("nbd://")<br>
<br>
And then you would be able to do, e.g.:<br>
<br>
  h.pread();<br>
  h.set_debug(false)<br>
<br>
But not:<br>
<br>
  h.set_export_name("/exp");<br>
<br>
as the object `h` would not even support that function.<br>
<br>
Anyway, even though it would be useful for libguestfs as well, thanks to the way<br>
these projects handle errors it is just something I consider "nice-to-have".<br>
<br>
Have a nice day,<br>
Martin<br>
<br>
>Rich.<br>
><br>
>-- <br>
>Richard Jones, Virtualization Group, Red Hat <a href="http://people.redhat.com/~rjones" rel="noreferrer" target="_blank">http://people.redhat.com/~rjones</a><br>
>Read my programming and virtualization blog: <a href="http://rwmj.wordpress.com" rel="noreferrer" target="_blank">http://rwmj.wordpress.com</a><br>
>virt-top is 'top' for virtual machines.  Tiny program with many<br>
>powerful monitoring features, net stats, disk stats, logging, etc.<br>
><a href="http://people.redhat.com/~rjones/virt-top" rel="noreferrer" target="_blank">http://people.redhat.com/~rjones/virt-top</a><br>
</blockquote></div>