All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marc-André Lureau" <marcandre.lureau@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "P. Berrange, Daniel" <berrange@redhat.com>,
	Sergio Lopez Pascual <slp@redhat.com>,
	"Hajnoczi, Stefan" <stefanha@gmail.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Armbruster, Markus" <armbru@redhat.com>,
	John Snow <jsnow@redhat.com>
Subject: Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now)
Date: Fri, 11 Sep 2020 18:00:44 +0400	[thread overview]
Message-ID: <CAJ+F1CKPyBfjPoaRc5j24swo8Bfy0D7m+txNk5cyAi47rOz2bw@mail.gmail.com> (raw)
In-Reply-To: <399aad6c-5d86-8988-a44a-e91d650e7273@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 3457 bytes --]

Hi

On Fri, Sep 11, 2020 at 5:08 PM Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 11/09/20 12:24, Paolo Bonzini wrote:
> >>
> >> - from_qemu_none(ptr: *const sys::P) -> T
> >>   Return a Rust type T for a const ffi pointer P.
> >>
> >> - from_qemu_full(ptr: *mut sys::P) -> T
> >>   Return a Rust type T for a ffi pointer P, taking ownership.
> >>
> >> - T::to_qemu_none() -> Stash<P>
> >>   Returns a borrowed ffi pointer P (using a Stash to destroy "glue"
> >>   storage data, if any).
> >>
> >> - T::to_qemu_full() -> P
> >>   Returns a ffi pointer P. (P resources are leaked/passed to C/ffi)
> >
> > I know these come from glib-rs, but still the names are awful. :)
>
> After studying a bit I managed to give a rational explanation of the
> above gut feeling.  Conversions in Rust usually follow this naming
> convention:
>
>         Name              Type                  Price
>         --------          --------------------  -----------
>         as_*, borrow      Borrowed -> Borrowed  Cheap
>         to_*, constructor Borrowed -> Owned     Expensive
>         from, into_*      Owned -> Owned        Any
>
> and we have
>
>         from_qemu_none    Borrowed -> Owned
>         to_qemu_none      Borrowed -> Borrowed
>         from_qemu_full    Owned -> Owned
>         to_qemu_full      Owned -> Owned
>
> So
>
> - from_qemu_none should be a "to_*" or "constructor" conversion (I used
> new_from_foreign)
>

new_ prefix is not very rusty.

from_raw() is common, and takes ownership.
from_ptr() (as in CStr) could be a candidate (although it wouldn't have the
same lifetime requirements)


> - to_qemu_none, even though in some cases it can be expensive, should be
> an "as_*" conversion (as_foreign).
>

as_ptr(), but since it's more complicated than just a pointer due to
temporary storage, it's not the best fit either...


> - from_qemu_full and to_qemu_full should be "from" or "into_*"
>

ok


>
> to_qemu_full() could also be split into a more expensive but flexible
> "to" variant and the cheaper "into" variant.  Just for the sake of
> example, I updated my demo by replacing the IntoRaw trait with these two:
>
>     trait ToForeign<T> {
>         fn to_foreign(&self) -> *mut T;
>     }
>
>     trait IntoForeign<T> {
>         fn into_foreign(self) -> *mut T;
>     }
>
> where the example implementations show the different cost quite clearly:
>
>     impl ToForeign<c_char> for String {
>         fn to_foreign(&self) -> *mut c_char {
>             unsafe { libc::strndup(self.as_ptr() as *const c_char,
>                                    self.len() as size_t) }
>         }
>     }
>
>     impl IntoForeign<c_char> for String {
>         fn into_foreign(self) -> *mut c_char {
>             let ptr = self.as_ptr();
>             forget(self);
>             ptr as *mut _
>         }
>     }
>
>
You corrected the \0-ending in the git tree. However, the memory allocator
(or the stack) may not be compatible with the one used in C.

 As for the general comparison with glib-rs traits, it's hard for me to say
upfront the pros and cons, I would need to modify this PoC for example. But
I must say I feel quite comfortable with the glib approach. It would be
nice to have some feedback from glib-rs maintainers about your proposal.

(my gut feeling is that we would be better sticking with something close to
glib, as it is likely we will end up using glib-rs at some point, and
having similar patterns should help each other)

[-- Attachment #2: Type: text/html, Size: 5072 bytes --]

  reply	other threads:[~2020-09-11 14:02 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-10 17:48 [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now) marcandre.lureau
2020-09-11 10:24 ` Paolo Bonzini
2020-09-11 13:08   ` Paolo Bonzini
2020-09-11 14:00     ` Marc-André Lureau [this message]
2020-09-11 15:17       ` Paolo Bonzini
2020-09-29 17:55         ` Marc-André Lureau
2020-09-29 18:23           ` Paolo Bonzini
2020-09-30  9:15             ` Marc-André Lureau
2020-09-30 14:02               ` Paolo Bonzini
2020-09-11 10:46 ` Daniel P. Berrangé
2020-09-11 11:03   ` Marc-André Lureau
2020-09-11 11:28   ` Paolo Bonzini
2020-09-11 11:31     ` Daniel P. Berrangé
2020-09-11 14:19     ` John Snow
2020-09-11 14:17 ` Marc-André Lureau
2020-09-21  9:16 ` Markus Armbruster
2020-09-21  9:30   ` Paolo Bonzini
2020-09-22 14:59     ` Markus Armbruster
2020-09-21 10:04   ` Marc-André Lureau
2020-09-22 15:09     ` Markus Armbruster
2020-09-22 16:35       ` Marc-André Lureau
2020-09-22 17:08         ` Paolo Bonzini
2020-09-29  7:45           ` Marc-André Lureau
2020-09-29 10:14             ` Paolo Bonzini
2020-09-29 10:34               ` Marc-André Lureau
2020-09-29 11:00                 ` Paolo Bonzini
2020-09-29 11:34                   ` Marc-André Lureau
2020-09-30  7:34                     ` Markus Armbruster
2020-09-30  7:51                       ` Marc-André Lureau
2020-09-30 13:14                         ` Paolo Bonzini
2020-09-22 16:52       ` Daniel P. Berrangé
2020-09-23 11:51         ` Markus Armbruster
2020-09-21 10:11   ` Marc-André Lureau
2020-09-22 15:37     ` Markus Armbruster
2020-09-22 16:25       ` Marc-André Lureau
2020-09-24  7:31         ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJ+F1CKPyBfjPoaRc5j24swo8Bfy0D7m+txNk5cyAi47rOz2bw@mail.gmail.com \
    --to=marcandre.lureau@gmail.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=slp@redhat.com \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.