All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Erik Schilling" <erik.schilling@linaro.org>
To: "Erik Schilling" <erik.schilling@linaro.org>,
	"Linux-GPIO" <linux-gpio@vger.kernel.org>
Cc: "Viresh Kumar" <viresh.kumar@linaro.org>,
	"Manos Pitsidianakis" <manos.pitsidianakis@linaro.org>
Subject: Re: [libgpiod][PATCH 1/3] bindings: rust: fix soundness of line_info modeling
Date: Thu, 28 Sep 2023 15:24:15 +0200	[thread overview]
Message-ID: <CVUL0PI4MCEG.3H1JSHTV7KKTN@ablu-work> (raw)
In-Reply-To: <20230927-rust-line-info-soundness-v1-1-990dce6f18ab@linaro.org>

> +/// Line info
> +///
> +/// This is the owned counterpart to [Info]. Due to a [Deref] implementation,
> +/// all functions of [Info] can also be called on this type.
> +#[derive(Debug)]
> +pub struct InfoOwned {
> +    info: *mut gpiod::gpiod_line_info,
> +}

While going through all the structs in order to add missing `Send`
implementations, it occured to me that it may be a bit confusing if
only this one type has the `Owned` suffix, while the others are also
"owned" but do not carry that suffix.

Not really sure how to resolve this... We could rename the non-owned
`Info` to something like `InfoRef` and turn `InfoOwned` back into
`Info`, but reading `&InfoRef` may be a bit weird?

Alternatively, we could rename all other structs to add the suffix...
Then, "Owned" would maybe sound confusing - given that no un-owned
variant exists.
Maybe "Box" would be a more suitable suffix in that case - borrowing
from the Box type name [1]?

Any opinions here?

[1] https://doc.rust-lang.org/std/boxed/struct.Box.html

  parent reply	other threads:[~2023-09-28 13:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-27 16:29 [libgpiod][PATCH 0/3] bindings: rust: fix modeling of line_info lifetimes Erik Schilling
2023-09-27 16:29 ` [libgpiod][PATCH 1/3] bindings: rust: fix soundness of line_info modeling Erik Schilling
2023-09-28 11:27   ` Viresh Kumar
2023-09-28 12:27     ` Erik Schilling
2023-09-29 10:39       ` Viresh Kumar
2023-09-29 10:58         ` Erik Schilling
2023-09-29 11:02           ` Viresh Kumar
2023-09-28 13:24   ` Erik Schilling [this message]
2023-09-29 10:39     ` Viresh Kumar
2023-09-29 11:06       ` Erik Schilling
2023-09-29 10:50     ` Manos Pitsidianakis
2023-09-27 16:29 ` [libgpiod][PATCH 2/3] bindings: rust: allow cloning line::Info -> line::OwnedInfo Erik Schilling
2023-09-28 12:52   ` Erik Schilling
2023-09-29 10:50     ` Viresh Kumar
2023-09-29 11:05       ` Erik Schilling
2023-09-27 16:29 ` [libgpiod][PATCH 3/3] bindings: rust: bump major for libgpiod crate Erik Schilling
2023-09-29 12:43   ` Bartosz Golaszewski
2023-09-29 12:45     ` Erik Schilling

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=CVUL0PI4MCEG.3H1JSHTV7KKTN@ablu-work \
    --to=erik.schilling@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=manos.pitsidianakis@linaro.org \
    --cc=viresh.kumar@linaro.org \
    /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.