From: Robin Murphy <robin.murphy@arm.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Asahi Lina <lina@asahilina.net>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Will Deacon" <will@kernel.org>, "Joerg Roedel" <joro@8bytes.org>,
"Hector Martin" <marcan@marcan.st>,
"Sven Peter" <sven@svenpeter.dev>,
"Arnd Bergmann" <arnd@arndb.de>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Alyssa Rosenzweig" <alyssa@rosenzweig.io>,
"Neal Gompa" <neal@gompa.dev>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
asahi@lists.linux.dev
Subject: Re: [PATCH 2/5] rust: device: Add a minimal RawDevice trait
Date: Fri, 24 Feb 2023 14:32:47 +0000 [thread overview]
Message-ID: <e6d6d928-4514-55b9-346d-2e5e82220729@arm.com> (raw)
In-Reply-To: <Y/jFeZzZVCpBGvGv@kroah.com>
On 2023-02-24 14:11, Greg Kroah-Hartman wrote:
> Thanks for the detailed rust explainations, I'd like to just highlight
> one thing:
>
> On Fri, Feb 24, 2023 at 10:15:12PM +0900, Asahi Lina wrote:
>> On 24/02/2023 20.23, Greg Kroah-Hartman wrote:
>>> And again, why are bindings needed for a "raw" struct device at all?
>>> Shouldn't the bus-specific wrappings work better?
>>
>> Because lots of kernel subsystems need to be able to accept "any" device
>> and don't care about the bus! That's what this is for.
>
> That's great, but:
>
>> All the bus
>> wrappers would implement this so they can be used as an argument for all
>> those subsystems (plus a generic one when you just need to pass around
>> an actual owned generic reference and no longer need bus-specific
>> operations - you can materialize that out of a RawDevice impl, which is
>> when get_device() would be called). That's why I'm introducing this now,
>> because both io_pgtable and rtkit need to take `struct device` pointers
>> on the C side so we need some "generic struct device" view on the Rust side.
>
> In looking at both ftkit and io_pgtable, those seem to be good examples
> of how "not to use a struct device", so trying to make safe bindings
> from Rust to these frameworks is very ironic :)
>
> rtkit takes a struct device pointer and then never increments it,
> despite saving it off, which is unsafe. It then only uses it to print
> out messages if things go wrong (or right in some cases), which is odd.
> So it can get away from using a device pointer entirely, except for the
> devm_apple_rtkit_init() call, which I doubt you want to call from rust
> code, right?
>
> for io_pgtable, that's a bit messier, you want to pass in a device that
> io_pgtable treats as a "device" but again, it is NEVER properly
> reference counted, AND, it is only needed to try to figure out the bus
> operations that dma memory should be allocated from for this device. So
> what would be better to save off there would be a pointer to the bus,
> which is constant and soon will be read-only so there are no lifetime
> rules needed at all (see the major struct bus_type changes going into
> 6.3-rc1 that will enable that to happen).
FWIW the DMA API *has* to know which specific device it's operating
with, since the relevant properties can and do vary even between
different devices within a single bus_type (e.g. DMA masks).
In the case of io-pgtable at least, there's no explicit refcounting
since the struct device must be the one representing the physical
platform/PCI/etc. device consuming the pagetable, so if that were to
disappear from underneath its driver while the pagetable is still in
use, things would already have gone very very wrong indeed :)
Cheers,
Robin.
> So the two subsystems you want to call from rust code don't properly
> handle the reference count of the object you are going to pass into it,
> and only need it for debugging and iommu stuff, which is really only the
> bus that the device is on, not good examples to start out with :)
>
> Yeah, this is yack-shaving, sorry, but it's how we clean up core
> subsystems for apis and implementations that are not really correct and
> were not noticed at the time.
>
> Can we see some users of this code posted so I can see how struct device
> is going to work in a rust driver? That's the thing I worry most about
> the rust/C interaction here as we have two different ways of thinking
> about reference counts from the two worlds and putting them together is
> going to be "interesting", as can be seen here already.
>
> thanks,
>
> greg k-h
next prev parent reply other threads:[~2023-02-24 14:33 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-24 10:53 [PATCH 0/5] rust: Add io_pgtable and RTKit abstractions Asahi Lina
2023-02-24 10:53 ` [PATCH 1/5] rust: Add a Sealed trait Asahi Lina
2023-02-24 10:53 ` [PATCH 2/5] rust: device: Add a minimal RawDevice trait Asahi Lina
2023-02-24 11:23 ` Greg Kroah-Hartman
2023-02-24 13:15 ` Asahi Lina
2023-02-24 14:11 ` Greg Kroah-Hartman
2023-02-24 14:19 ` Greg Kroah-Hartman
2023-02-24 14:44 ` Asahi Lina
2023-02-24 15:25 ` Greg Kroah-Hartman
2023-02-24 15:45 ` Asahi Lina
2023-02-25 17:07 ` alyssa
2023-02-24 14:32 ` Robin Murphy [this message]
2023-02-24 14:48 ` Asahi Lina
2023-02-24 15:14 ` Robin Murphy
2023-02-24 16:23 ` Asahi Lina
2023-02-24 19:22 ` Miguel Ojeda
2023-03-05 6:52 ` Wedson Almeida Filho
2023-02-24 15:32 ` Greg Kroah-Hartman
2023-02-24 18:52 ` Robin Murphy
2023-02-25 7:00 ` Greg Kroah-Hartman
2023-02-24 14:43 ` Asahi Lina
2023-02-24 15:24 ` Greg Kroah-Hartman
2023-02-24 15:42 ` Asahi Lina
2023-02-24 10:53 ` [PATCH 3/5] rust: io_pgtable: Add io_pgtable abstraction Asahi Lina
2023-02-24 10:53 ` [PATCH 4/5] rust: soc: apple: rtkit: Add Apple RTKit abstraction Asahi Lina
2023-02-24 10:53 ` [PATCH 5/5] rust: device: Add a stub abstraction for devices Asahi Lina
2023-02-24 11:19 ` Greg Kroah-Hartman
2023-02-24 15:10 ` Asahi Lina
2023-02-24 15:34 ` Greg Kroah-Hartman
2023-02-24 15:51 ` Asahi Lina
2023-02-24 16:31 ` Greg Kroah-Hartman
2023-02-24 16:53 ` Asahi Lina
2023-03-05 6:39 ` Wedson Almeida Filho
2023-03-09 11:24 ` Greg Kroah-Hartman
2023-03-09 16:46 ` Wedson Almeida Filho
2023-03-09 17:11 ` Greg Kroah-Hartman
2023-03-09 19:06 ` Wedson Almeida Filho
2023-03-13 17:01 ` Gary Guo
2023-03-09 19:43 ` Miguel Ojeda
2023-03-13 17:52 ` Gary Guo
2023-03-13 18:05 ` Boqun Feng
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=e6d6d928-4514-55b9-346d-2e5e82220729@arm.com \
--to=robin.murphy@arm.com \
--cc=alex.gaynor@gmail.com \
--cc=alyssa@rosenzweig.io \
--cc=arnd@arndb.de \
--cc=asahi@lists.linux.dev \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=joro@8bytes.org \
--cc=lina@asahilina.net \
--cc=linux-kernel@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=neal@gompa.dev \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sven@svenpeter.dev \
--cc=wedsonaf@gmail.com \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).