All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Hindborg <a.hindborg@kernel.org>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@gmail.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Joel Becker" <jlbec@evilplan.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>, "Will Deacon" <will@kernel.org>,
	"Waiman Long" <longman@redhat.com>,
	"Fiona Behrens" <me@kloenk.dev>,
	"Charalampos Mitrodimas" <charmitro@posteo.net>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Breno Leitao" <leitao@debian.org>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 1/3] rust: configfs: introduce rust support for configfs
Date: Thu, 01 May 2025 13:31:57 +0200	[thread overview]
Message-ID: <87msbw1s9e.fsf@kernel.org> (raw)
In-Reply-To: <CANiq72mS_HV5rDjP+t+k0jX9QeAgF2SB9_xX54iEBTH-GoPuEg@mail.gmail.com> (Miguel Ojeda's message of "Thu, 01 May 2025 12:52:10 +0200")

"Miguel Ojeda" <miguel.ojeda.sandonis@gmail.com> writes:

> On Thu, May 1, 2025 at 12:15 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>
>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>>
>> ---
>>
>
> Spurious newlines.

The one just before the cut?

>
>> This patch is a direct dependency for `rnull`, the rust null block driver.
>> ---
>
> By the way, you don't need this `---`.

b4 adds it 🤷

>
>> +//! `configfs` interface.
>
> I don't know if configfs is supposed to be written in code spans, but
> I appreciate you are trying to be throughout in your Markdown use ;)
> It may be easier to read to not have it in code spans, since we have
> many already and it is not code anyway.

OK

>
> By the way, you may want to mention somehow the title they use in
> their docs: "Userspace-driven Kernel Object Configuration".

Will do.

>
>> +//! See the [rust_configfs.rs] sample for a full example use of this module.
>
> Files are, though, like the C header below, so: [`rust_configfs.rs`]

OK

>
>> +/// with configfs, embed a field of this type into your kernel module struct.
>
> Either with or without a code span, i.e. being consistent is best.

I am! Consistently inconsistent. Very much so in this series. Will fix.

>
>> +    /// Return the address of the `bindings::config_group` embedded in `Self`.
>
> I think you may be able to use intra-doc links for [`Self`].

Thanks. Would be nice with a lint for missed intra-doc links.

>
>> +        let c_group: *mut bindings::config_group =
>> +        // SAFETY: By function safety requirements, `item` is embedded in a
>> +        // `config_group`.
>> +            unsafe { container_of!(item, bindings::config_group, cg_item) }.cast_mut();
>
> It doesn't work to put the safety comment on top? (We had issues
> similar to this in the past, so if it is intentional, that is fine).

Clippy gets mad if we move it up. Because rustfmt wants the unsafe block
to a new line:

  warning: unsafe block missing a safety comment
    --> rust/kernel/configfs.rs:557:13
      |
  557 |             unsafe { container_of!(item, bindings::config_group, cg_item) }.cast_mut();
      |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      |
      = help: consider adding a safety comment on the preceding line
      = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#undocumented_unsafe_blocks
      = note: requested on the command line with `-W clippy::undocumented-unsafe-blocks`

>
>> +/// This type is constructed statically at compile time and is by the
>> +/// [`kernel::configfs_attrs`] macro.
>
> Sentence is missing something. Also, we never used `# Note` yet, but I
> guess it is fine.

Thanks, rephrased:

  # Note
  
  Instances of this type are constructed statically at compile by the
  [`kernel::configfs_attrs`] macro.

>
>> +    /// Null terminated Array of pointers to `Attribute`. The type is `c_void`
>
> Intar-doc link(s)?
>
>> +        // We need a space at the end of our list for a null terminator.
>> +        if I >= N - 1 {
>> +            kernel::build_error!("Invalid attribute index");
>> +        }
>
> Would the following work instead?
>
>     const { assert!(I < N - 1, "Invalid attribute index") };
>
> (Please double-check it actually catches the cases you need)

The reason I choose build_error is that if this should somehow end up
being evaluated in non-const context at some point, I want the build to
fail if the condition is not true. I don't think I get that with assert?


Best regards,
Andreas Hindborg




  reply	other threads:[~2025-05-01 11:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-01 10:14 [PATCH v6 0/3] rust: configfs abstractions Andreas Hindborg
2025-05-01 10:14 ` [PATCH v6 1/3] rust: configfs: introduce rust support for configfs Andreas Hindborg
2025-05-01 10:52   ` Miguel Ojeda
2025-05-01 11:31     ` Andreas Hindborg [this message]
2025-05-01 14:08       ` Miguel Ojeda
2025-05-01 18:11         ` Andreas Hindborg
2025-05-01 19:26           ` Miguel Ojeda
2025-05-01 19:51             ` Andreas Hindborg
2025-05-01 21:28               ` Miguel Ojeda
2025-05-01 21:46                 ` Miguel Ojeda
2025-05-02  6:57                   ` Andreas Hindborg
2025-05-03 11:18                     ` Miguel Ojeda
2025-05-05  7:50                       ` Andreas Hindborg
2025-05-06 11:18                         ` Miguel Ojeda
2025-05-06 11:31                           ` Andreas Hindborg
2025-05-06 11:51                             ` Andreas Hindborg
2025-05-01 10:14 ` [PATCH v6 2/3] rust: configfs: add a sample demonstrating configfs usage Andreas Hindborg
2025-05-02  7:27   ` Charalampos Mitrodimas
2025-05-02 12:05     ` Andreas Hindborg
2025-05-01 10:14 ` [PATCH v6 3/3] MAINTAINERS: add configfs Rust abstractions Andreas Hindborg

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=87msbw1s9e.fsf@kernel.org \
    --to=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=charmitro@posteo.net \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=jlbec@evilplan.org \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=me@kloenk.dev \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=mingo@redhat.com \
    --cc=ojeda@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --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 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.