From: Valentin Obst <kernel@valentinobst.de>
To: dirk.behme@de.bosch.com
Cc: ojeda@kernel.org, rust-for-linux@vger.kernel.org,
Valentin Obst <kernel@valentinobst.de>
Subject: Re: [PATCH] docs: rust: extend abstraction and binding documentation
Date: Tue, 6 Feb 2024 09:28:10 +0100 [thread overview]
Message-ID: <20240206082810.17431-1-kernel@valentinobst.de> (raw)
In-Reply-To: <20240206065429.1933397-1-dirk.behme@de.bosch.com>
+.. code-block::
+
+ rust/bindings/
+ (rust/helpers.c)
+
+ include/ -----+ <-+
+ | |
+ drivers/ rust/kernel/ +----------+ <-+ |
+ fs/ | bindgen | |
+ .../ +-------------------+ +----------+ --+ |
+ | Abstractions | | |
+ +---------+ | +------+ +------+ | +----------+ | |
+ | my_foo | -----> | | foo | | bar | | -------> | Bindings | <-+ |
+ | driver | Safe | | sub- | | sub- | | Unsafe | | |
+ +---------+ | |system| |system| | | bindings | <-----+
+ | | +------+ +------+ | | crate | |
+ | | kernel crate | +----------+ |
+ | +-------------------+ |
+ | |
+ +------------------# FORBIDDEN #--------------------------------+
+
+The main idea is to encapsulate all ``unsafe()`` handling in the abstractions reviewed
+and documented carefully. These are considered to be sound then.
Maybe reword a bit to make it smoother:
The main idea is to encapsulate all ``unsafe()`` handling in carefully
reviewed and documented abstractions. These are then considered to be
sound.
> With this model
> +it is assumed that users of the abstractions ("my_foo driver") can't do anything
> +unsound if
Not sure if 'assumed' is the best word here. Isn't the soundness
of safe code implied by the soundness of the safe abstractions it is
using? In that case one could use stronger words and say, e.g.,
"... ensured that ...".
> +
> +#. the abstractions are sound
> +#. they don't use ``unsafe()``
> +
> +Bindings
> +~~~~~~~~
> +
> +By including a C header from ``include/`` into ``rust/bindings/bindings_helper.h``
> +the ``bindgen`` tool will auto-generate the bindings for the included subsystem.
> +See the ``*_generated.rs`` output files in the ``rust/bindings/`` directory.
> +
> +For parts of the C header ``bindgen`` doesn't auto generate, e.g. C ``inline``
> +functions, there is the option to add a small wrapper function to ``rust/helpers.c``
> +to make it available for the Rust side as well.
> +
> +Abstractions
> +~~~~~~~~~~~~
> +
> +Abstractions are the glue layer between the bindings and the in-kernel users. E.g.
> +the drivers or file systems written in Rust.
Wouldn't start a sentence with 'e.g.'. I'd either write it out, i.e.,
"For example,", or not start a new sentence: "... users, e.g. ...".
> They are located in ``rust/kernel/``
> +and are supposed to make the ``unsafe()`` access to the bindings as-safe-as-possible
> +for their users.
> +
I think one could make it more clear that users are not expected to
access the bindings directly, e.g.:
... and their role is to encapsulate the ``unsafe()`` access to the
bindings into a safe API that they expose to their users.
Note: Looks like you only sent this to Miguel and RFL list (intentional?).
- Best Valentin
next prev parent reply other threads:[~2024-02-06 9:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-06 6:54 [PATCH] docs: rust: extend abstraction and binding documentation Dirk Behme
2024-02-06 8:28 ` Valentin Obst [this message]
2024-02-06 19:35 ` Miguel Ojeda
2024-02-07 5:32 ` Behme Dirk (CM/ESO2)
2024-02-08 10:36 ` Benno Lossin
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=20240206082810.17431-1-kernel@valentinobst.de \
--to=kernel@valentinobst.de \
--cc=dirk.behme@de.bosch.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.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).