All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Hindborg <a.hindborg@kernel.org>
To: "Alistair Francis" <alistair@alistair23.me>
Cc: <bhelgaas@google.com>,  <rust-for-linux@vger.kernel.org>,
	<lukas@wunner.de>,  <gary@garyguo.net>,
	 <akpm@linux-foundation.org>, <tmgross@umich.edu>,
	 <boqun.feng@gmail.com>,  <ojeda@kernel.org>,
	<linux-cxl@vger.kernel.org>,  <bjorn3_gh@protonmail.com>,
	<me@kloenk.dev>,  <linux-kernel@vger.kernel.org>,
	<aliceryhl@google.com>,  <alistair.francis@wdc.com>,
	<linux-pci@vger.kernel.org>,  <benno.lossin@proton.me>,
	<alex.gaynor@gmail.com>,  <Jonathan.Cameron@huawei.com>,
	<alistair23@gmail.com>,  <wilfred.mallawa@wdc.com>
Subject: Re: [PATCH v5 00/11] rust: bindings: Auto-generate inline static functions
Date: Tue, 07 Jan 2025 12:47:10 +0100	[thread overview]
Message-ID: <878qrm6e2p.fsf@kernel.org> (raw)
In-Reply-To: <20250107035058.818539-1-alistair@alistair23.me> (Alistair Francis's message of "Tue, 07 Jan 2025 13:50:47 +1000")

"Alistair Francis" <alistair@alistair23.me> writes:

> The kernel includes a large number of static inline functions that are
> defined in header files. One example is the crypto_shash_descsize()
> function which is defined in hash.h as
>
> ```
> static inline unsigned int crypto_shash_descsize(struct crypto_shash *tfm)
> {
>         return tfm->descsize;
> }
> ```
>
> bindgen is currently unable to generate bindings to these functions as
> they are not publically exposed (they are static after all).
>
> The Rust code currently uses rust_helper_* functions, such as
> rust_helper_alloc_pages() for example to call the static inline
> functions. But this is a hassle as someone needs to write a C helper
> function.
>
> Instead we can use the bindgen wrap-static-fns feature. The feature
> is marked as experimental, but has recently been promoted to
> non-experimental (depending on your version of bindgen).
>
> By supporting wrap-static-fns we automatically generate a C file called
> extern.c that exposes the static inline functions, for example like this
>
> ```
> unsigned int crypto_shash_descsize__extern(struct crypto_shash *tfm) { return crypto_shash_descsize(tfm); }
> ```
>
> The nice part is that this is auto-generated.
>
> We then also get a bindings_generate_static.rs file with the Rust
> binding, like this
>
> ```
> extern "C" {
>     #[link_name = "crypto_shash_descsize__extern"]
>     pub fn crypto_shash_descsize(tfm: *mut crypto_shash) -> core::ffi::c_uint;
> }
> ```
>
> So now we can use the static inline functions just like normal
> functions.
>
> There are a bunch of static inline functions that don't work though, because
> the C compiler fails to build extern.c:
>  * functions with inline asm generate "operand probably does not match constraints"
>    errors (rip_rel_ptr() for example)
>  * functions with bit masks (u32_encode_bits() and friends) result in
>    "call to ‘__bad_mask’ declared with attribute error: bad bitfield mask"
>    errors
>
> As well as that any static inline function that calls a function that has been
> kconfig-ed out will fail to link as the function being called isn't built
> (mdio45_ethtool_gset_npage for example)
>
> Due to these failures we use a allow-list system (where functions must
> be manually enabled).
>
> This series adds support for bindgen generating wrappers for inline statics and
> then converts the existing helper functions to this new method. This doesn't
> work for C macros, so we can't reamove all of the helper functions, but we
> can remove most.
>
> v5:
>  - Rebase on latest rust-next on top of v6.13-rc6
>  - Allow support for LTO inlining (not in this series, see
>    https://github.com/alistair23/linux/commit/e6b847324b4f5e904e007c0e288c88d2483928a8)

Thanks! Since Gary just sent v2 of the LTO patch [1], could you rebase
on that and list it as a dependency? If you are using b4 there is a nice
feature for that [2].


Best regards,
Andreas Hindborg


[1] https://lore.kernel.org/all/20250105194054.545201-1-gary@garyguo.net/
[2] https://b4.docs.kernel.org/en/latest/contributor/prep.html#working-with-series-dependencies


  parent reply	other threads:[~2025-01-07 11:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <PsAMnW6hScU1fLV8ucb6wOkHECGXCrwXeSEfeVs3Hc-zbwrML674jGT8H_XNvWiF6EdymYJZSusanBrtAsZjAg==@protonmail.internalid>
2025-01-07  3:50 ` [PATCH v5 00/11] rust: bindings: Auto-generate inline static functions Alistair Francis
2025-01-07  3:50   ` [PATCH v5 01/11] rust: bindings: Support some " Alistair Francis
2025-01-07  3:50   ` [PATCH v5 02/11] rust: helpers: Remove blk helper Alistair Francis
2025-01-07  3:50   ` [PATCH v5 03/11] rust: helpers: Remove err helper Alistair Francis
2025-01-07  3:50   ` [PATCH v5 04/11] rust: helpers: Remove kunit helper Alistair Francis
2025-01-07  3:50   ` [PATCH v5 05/11] rust: helpers: Remove some page helpers Alistair Francis
2025-01-07  3:50   ` [PATCH v5 06/11] rust: helpers: Remove rbtree helper Alistair Francis
2025-01-07  3:50   ` [PATCH v5 07/11] rust: helpers: Remove some refcount helpers Alistair Francis
2025-01-07  3:50   ` [PATCH v5 08/11] rust: helpers: Remove signal helper Alistair Francis
2025-01-07  3:50   ` [PATCH v5 09/11] rust: helpers: Remove some spinlock helpers Alistair Francis
2025-01-07  3:50   ` [PATCH v5 10/11] rust: helpers: Remove some task helpers Alistair Francis
2025-01-07  3:50   ` [PATCH v5 11/11] rust: helpers: Remove uaccess helpers Alistair Francis
2025-01-07 11:47   ` Andreas Hindborg [this message]
2025-01-14  6:02     ` [PATCH v5 00/11] rust: bindings: Auto-generate inline static functions Alistair Francis
2025-03-18  6:53       ` Alistair Francis
2025-03-18 14:50         ` Tamir Duberstein

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=878qrm6e2p.fsf@kernel.org \
    --to=a.hindborg@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=alistair.francis@wdc.com \
    --cc=alistair23@gmail.com \
    --cc=alistair@alistair23.me \
    --cc=benno.lossin@proton.me \
    --cc=bhelgaas@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=me@kloenk.dev \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=wilfred.mallawa@wdc.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.