rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: FUJITA Tomonori <fujita.tomonori@gmail.com>
Cc: gregkh@linuxfoundation.org, netdev@vger.kernel.org,
	 rust-for-linux@vger.kernel.org, andrew@lunn.ch,
	tmgross@umich.edu,  wedsonaf@gmail.com
Subject: Re: [PATCH net-next v3 1/3] rust: core abstractions for network PHY drivers
Date: Fri, 13 Oct 2023 13:59:12 +0200	[thread overview]
Message-ID: <CANiq72mgeVrcGcHXo1xjaRL1ix3vUsGbtk179kpyJ6GAe9MMVg@mail.gmail.com> (raw)
In-Reply-To: <20231012.081826.1846197263913130802.fujita.tomonori@gmail.com>

On Thu, Oct 12, 2023 at 1:18 AM FUJITA Tomonori
<fujita.tomonori@gmail.com> wrote:
>
> IIRC, Andrew prefers to avoid creating a temporary rust variant (Greg
> does too, I understand). I guess that only solusion that both Rust and
> C devs would be happy with is generating safe Rust code from C. The

As far as I understand, the workaround I just suggested in the
previous reply was not discussed so far. I am not sure which of the
alternatives you mean by the "temporary rust variant", so I may be
misunderstanding your message.

> solution is still a prototype and I don't know when it will be
> available (someone knows?).

If no alternative is good enough, and you do not have time to
implement one of the better solutions, then we need to wait until one
of us (or somebody else) implements it. I understand that can be
frustrating, but we cannot really agree to start using
`--rustified-enum` or, in general, ways to introduce UB where we
already have known solutions.

Instead, we prefer to spend some time iterating on this sort of
problem. It is also not the first time at all we have done this, e.g.
see `pin-init`. It is all about trying to avoid compromising, unless
the solution is really far away.

Having said that, to try to unblock things, I spent some time
prototyping the workaround I suggested, see below [1]. That catches
the "new C variant added" desync between Rust and C.

For instance, if I add a `PHY_NEW` variant, then I get:

    error[E0005]: refutable pattern in function argument
         --> rust/bindings/bindings_enum_check.rs:29:6
          |
    29    |       (phy_state::PHY_DOWN
          |  ______^
    30    | |     | phy_state::PHY_READY
    31    | |     | phy_state::PHY_HALTED
    32    | |     | phy_state::PHY_ERROR
    ...     |
    35    | |     | phy_state::PHY_NOLINK
    36    | |     | phy_state::PHY_CABLETEST): phy_state,
          | |______________________________^ pattern
`phy_state::PHY_NEW` not covered
          |
    note: `phy_state` defined here
         --> rust/bindings/bindings_generated_enum_check.rs:60739:10
          |
    60739 | pub enum phy_state {
          |          ^^^^^^^^^
    ...
    60745 |     PHY_NEW = 5,
          |     ------- not covered
          = note: the matched value is of type `phy_state`

It seems to work fine and would allow us to use the wildcard `_`
without risk of desync, and without needing changes on the C enum.

> Sorry, there's no excuse. I should have done better. I'll make sure
> that the code is warning-free.

No problem at all -- it is all fine. I hope the workaround is suitable
and unblocks you. Please let me know and I can send it as a patch.

However, I would still prefer that it is done in `bindgen` -- when we
talked about that possibility in the weekly meeting a couple days ago,
we thought it could be doable to have it ready for the next kernel
version if somebody steps up to do it now. I could do it, but not
before LPC.

Cheers,
Miguel

[1]

diff --git a/rust/.gitignore b/rust/.gitignore
index d3829ffab80b..1a76ad0d6603 100644
--- a/rust/.gitignore
+++ b/rust/.gitignore
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0

 bindings_generated.rs
+bindings_generated_enum_check.rs
 bindings_helpers_generated.rs
 doctests_kernel_generated.rs
 doctests_kernel_generated_kunit.c
diff --git a/rust/Makefile b/rust/Makefile
index 87958e864be0..4a1c7a48dfad 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -15,6 +15,7 @@ always-$(CONFIG_RUST) += libmacros.so
 no-clean-files += libmacros.so

 always-$(CONFIG_RUST) += bindings/bindings_generated.rs
bindings/bindings_helpers_generated.rs
+always-$(CONFIG_RUST) += bindings/bindings_generated_enum_check.rs
 obj-$(CONFIG_RUST) += alloc.o bindings.o kernel.o
 always-$(CONFIG_RUST) += exports_alloc_generated.h
exports_bindings_generated.h \
     exports_kernel_generated.h
@@ -341,6 +342,19 @@ $(obj)/bindings/bindings_generated.rs:
$(src)/bindings/bindings_helper.h \
     $(src)/bindgen_parameters FORCE
        $(call if_changed_dep,bindgen)

+$(obj)/bindings/bindings_generated_enum_check.rs: private
bindgen_target_flags = \
+    $(shell grep -v '^#\|^$$' $(srctree)/$(src)/bindgen_parameters) \
+    --default-enum-style rust
+$(obj)/bindings/bindings_generated_enum_check.rs: private
bindgen_target_extra = ; \
+    OBJTREE=$(abspath $(objtree)) $(RUSTC_OR_CLIPPY) $(rust_flags)
$(rustc_target_flags) \
+        --crate-type rlib -L$(objtree)/$(obj) \
+        --emit=dep-info=$(obj)/bindings/.bindings_enum_check.rs.d \
+        --emit=metadata=$(obj)/bindings/libbindings_enum_check.rmeta \
+        --crate-name enum_check $(obj)/bindings/bindings_enum_check.rs
+$(obj)/bindings/bindings_generated_enum_check.rs:
$(src)/bindings/bindings_helper.h \
+    $(src)/bindings/bindings_enum_check.rs $(src)/bindgen_parameters FORCE
+       $(call if_changed_dep,bindgen)
+
 $(obj)/uapi/uapi_generated.rs: private bindgen_target_flags = \
     $(shell grep -v '^#\|^$$' $(srctree)/$(src)/bindgen_parameters)
 $(obj)/uapi/uapi_generated.rs: $(src)/uapi/uapi_helper.h \
diff --git a/rust/bindings/bindings_enum_check.rs
b/rust/bindings/bindings_enum_check.rs
new file mode 100644
index 000000000000..7c62bab12ea1
--- /dev/null
+++ b/rust/bindings/bindings_enum_check.rs
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Bindings exhaustiveness enum check.
+//!
+//! Eventually, this should be replaced by a safe version of
`--rustified-enum`, see
+//! https://github.com/rust-lang/rust-bindgen/issues/2646.
+
+#![no_std]
+#![allow(
+    clippy::all,
+    dead_code,
+    missing_docs,
+    non_camel_case_types,
+    non_upper_case_globals,
+    non_snake_case,
+    improper_ctypes,
+    unreachable_pub,
+    unsafe_op_in_unsafe_fn
+)]
+
+include!(concat!(
+    env!("OBJTREE"),
+    "/rust/bindings/bindings_generated_enum_check.rs"
+));
+
+fn check_phy_state(
+    (phy_state::PHY_DOWN
+    | phy_state::PHY_READY
+    | phy_state::PHY_HALTED
+    | phy_state::PHY_ERROR
+    | phy_state::PHY_UP
+    | phy_state::PHY_RUNNING
+    | phy_state::PHY_NOLINK
+    | phy_state::PHY_CABLETEST): phy_state,
+) {
+}

  reply	other threads:[~2023-10-13 11:59 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-09  1:39 [PATCH net-next v3 0/3] Rust abstractions for network PHY drivers FUJITA Tomonori
2023-10-09  1:39 ` [PATCH net-next v3 1/3] rust: core " FUJITA Tomonori
2023-10-09  3:17   ` Trevor Gross
2023-10-09 12:19   ` Benno Lossin
2023-10-09 13:02     ` Andrew Lunn
2023-10-09 13:56       ` Benno Lossin
2023-10-09 14:13         ` Andrew Lunn
2023-10-11 14:16     ` FUJITA Tomonori
2023-10-09 12:59   ` Miguel Ojeda
2023-10-09 13:49     ` FUJITA Tomonori
2023-10-09 14:32       ` Miguel Ojeda
2023-10-09 15:15         ` FUJITA Tomonori
2023-10-09 15:19           ` Miguel Ojeda
2023-10-09 15:11       ` Greg KH
2023-10-09 15:24         ` FUJITA Tomonori
2023-10-09 15:39           ` Miguel Ojeda
2023-10-09 15:50             ` FUJITA Tomonori
2023-10-11  9:59               ` Miguel Ojeda
2023-10-11 23:18                 ` FUJITA Tomonori
2023-10-13 11:59                   ` Miguel Ojeda [this message]
2023-10-13 15:15                     ` FUJITA Tomonori
2023-10-13 18:33                       ` Miguel Ojeda
2023-10-14 12:31                         ` FUJITA Tomonori
2023-10-14 16:19                           ` Miguel Ojeda
2023-10-12  0:29                 ` FUJITA Tomonori
2023-10-09 21:07           ` Trevor Gross
2023-10-09 21:21             ` Andrew Lunn
2023-10-11  7:04             ` FUJITA Tomonori
2023-10-09 13:54     ` Andrew Lunn
2023-10-09 14:48       ` Miguel Ojeda
2023-10-09 17:04         ` Andrew Lunn
2023-10-12  3:59     ` FUJITA Tomonori
2023-10-12  4:43       ` Trevor Gross
2023-10-12  7:09         ` FUJITA Tomonori
2023-10-11 18:29   ` Boqun Feng
2023-10-12  5:58     ` FUJITA Tomonori
2023-10-12  6:34       ` Boqun Feng
2023-10-12  6:44         ` FUJITA Tomonori
2023-10-12  7:02           ` FUJITA Tomonori
2023-10-12  7:13             ` Boqun Feng
2023-10-12  7:32               ` Trevor Gross
2023-10-12  7:58                 ` FUJITA Tomonori
2023-10-12  9:10                   ` Benno Lossin
2023-10-13  4:17                     ` Boqun Feng
2023-10-13  5:45                       ` FUJITA Tomonori
2023-10-13  7:56                         ` Benno Lossin
2023-10-13  9:53                           ` FUJITA Tomonori
2023-10-13 10:03                             ` Benno Lossin
2023-10-13 10:53                               ` FUJITA Tomonori
2023-10-14  7:47                                 ` Benno Lossin
2023-10-14 21:55                                   ` Andrew Lunn
2023-10-14 22:18                                     ` Benno Lossin
2023-10-14 22:33                                       ` Andrew Lunn
2023-10-14  4:11                             ` Boqun Feng
2023-10-14 11:59                             ` Miguel Ojeda
2023-10-12  7:07           ` Boqun Feng
2023-10-09  1:39 ` [PATCH net-next v3 2/3] MAINTAINERS: add Rust PHY abstractions to the ETHERNET PHY LIBRARY FUJITA Tomonori
2023-10-09  1:39 ` [PATCH net-next v3 3/3] net: phy: add Rust Asix PHY driver FUJITA Tomonori
2023-10-09  3:22   ` Trevor Gross
2023-10-09  7:23   ` Jiri Pirko
2023-10-09 10:58     ` Miguel Ojeda
2023-10-09 11:41     ` FUJITA Tomonori
2023-10-09 12:32     ` Andrew Lunn
2023-10-09 14:01       ` Miguel Ojeda
2023-10-09 14:31         ` Andrew Lunn
2023-10-09 15:27           ` Miguel Ojeda
2023-10-09 15:35             ` Miguel Ojeda
2023-10-09 16:09               ` Andrew Lunn
2023-10-09 10:10   ` Greg KH
2023-10-12 11:57     ` FUJITA Tomonori
2023-10-09 12:42   ` Benno Lossin
2023-10-09 13:15     ` Andrew Lunn
2023-10-09 13:45       ` Benno Lossin
2023-10-09 12:48 ` [PATCH net-next v3 0/3] Rust abstractions for network PHY drivers Andrew Lunn
2023-10-09 12:53   ` Miguel Ojeda
2023-10-09 13:06     ` Greg KH
2023-10-09 14:13       ` Miguel Ojeda
2023-10-09 14:52         ` Greg KH
2023-10-09 15:06           ` Miguel Ojeda
2023-10-09 15:14             ` Greg KH
2023-10-09 15:15               ` Miguel Ojeda
2023-10-09 13:24     ` Andrew Lunn
2023-10-09 13:36       ` Miguel Ojeda
2023-10-09 14:21     ` Andrea Righi
2023-10-09 14:22       ` Miguel Ojeda
2023-10-09 14:56       ` Andrew Lunn
2023-10-09 15:04         ` Greg KH
2023-10-09 15:10           ` Miguel Ojeda
2023-10-09 15:15             ` Miguel Ojeda
2023-10-09 14:56       ` Greg KH
2023-10-09 15:09         ` Andrea Righi

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=CANiq72mgeVrcGcHXo1xjaRL1ix3vUsGbtk179kpyJ6GAe9MMVg@mail.gmail.com \
    --to=miguel.ojeda.sandonis@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=fujita.tomonori@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=netdev@vger.kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=wedsonaf@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 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).