Message-ID: <7e6874d0-786d-4e02-a203-a2524cf8ff9e@proton.me>
Date: Wed, 03 Apr 2024 10:29:12 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Andreas Hindborg <nmi@...aspace.dk>
Cc: Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>, Keith Busch <kbusch@...nel.org>, Damien Le Moal <Damien.LeMoal@....com>, Bart Van Assche <bvanassche@....org>, Hannes Reinecke <hare@...e.de>, "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>, Andreas Hindborg <a.hindborg@...sung.com>, Niklas Cassel <Niklas.Cassel@....com>, Greg KH <gregkh@...uxfoundation.org>, Matthew Wilcox <willy@...radead.org>, Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, Wedson Almeida Filho <wedsonaf@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>, Alice Ryhl <aliceryhl@...gle.com>, Chaitanya Kulkarni <chaitanyak@...dia.com>, Luis Chamberlain <mcgrof@...nel.org>, Yexuan Yang <1182282462@...t.edu.cn>, Sergio González Collado <sergio.collado@...il.com>, Joel Granados <j.granados@...sung.com>, "Pankaj Raghav (Samsung)" <kernel@...kajraghav.com>, Daniel Gomez
	<da.gomez@...sung.com>, open list <linux-kernel@...r.kernel.org>, "rust-for-linux@...r.kernel.org" <rust-for-linux@...r.kernel.org>, "lsf-pc@...ts.linux-foundation.org" <lsf-pc@...ts.linux-foundation.org>, "gost.dev@...sung.com" <gost.dev@...sung.com>
Subject: Re: [RFC PATCH 4/5] rust: block: add rnull, Rust null_blk implementation

On 03.04.24 11:47, Andreas Hindborg wrote:
> Benno Lossin <benno.lossin@...ton.me> writes:
> 
> [...]
> 
>>
>>
>> So I did some digging and there are multiple things at play. I am going
>> to explain the second error first, since that one might be a problem
>> with `pin_init`:
>> - the `params` extension of the `module!` macro creates constants with
>>     snake case names.
>> - your `QueueData` struct has the same name as a field.
>> - `pin_init!` generates `let $field_name = ...` statements for each
>>     field you initialize
>>
>> Now when you define a constant in Rust, you are able to pattern-match
>> with that constant, eg:
>>
>>       const FOO: u8 = 0;
>>
>>       fn main() {
>>           match 10 {
>>               FOO => println!("foo"),
>>               _ => {}
>>           }
>>       }
>>
>> So when you do `let FOO = x;`, then it interprets `FOO` as the constant.
>> This is still true if the constant has a snake case name.
>> Since the expression in the `pin_init!` macro has type
>> `DropGuard<$field_type>`, we get the error "expected
>> `DropGuard<IRQMode>`, found `__rnull_mod_irq_mode`".
> 
> Thanks for the analysis!
> 
> So in this expanded code:
> 
> 1   {
> 2       unsafe { ::core::ptr::write(&raw mut ((*slot).irq_mode), irq_mode) };
> 3   }
> 4   let irq_mode = unsafe {
> 5       $crate::init::__internal::DropGuard::new(&raw mut ((*slot).irq_mode))
> 6   };
> 
> the `irq_mode` on line 2 will refer to the correct thing, but the one on
> line 6 will be a pattern match against a constant? That is really
> surprising to me. Can we make the let binding in line 6 be `let
> irq_mode_pin_init` or something similar?

The first occurrence of `irq_mode` in line 2 will refer to the field of
`QueueData`. The second one in line 2 will refer to the constant.
The one in line 4 is a pattern-match of the constant (since the type of
the constant is a fieldless struct, only one value exists. Thus making
the match irrefutable.) The occurrence in line 5 is again referring to
the field of `QueueData`.

If you have a constant `FOO`, you are unable to create a local binding
with the name `FOO`. So by creating the `irq_mode` constant, you cannot
create (AFAIK) a `irq_mode` local variable (if the constant is in-scope).

> 
>>
>> Now to the first error, this is a problem with the parameter handling of
>> `module`. By the same argument above, your let binding in line 104:
>>
>>       let irq_mode = (*irq_mode.read()).try_into()?;
>>
>> Tries to pattern-match the `irq_mode` constant with the right
>> expression. Since you use the `try_into` function, it tries to search
>> for a `TryInto` implementation for the type of `irq_mode` which is
>> generated by the `module!` macro. The type is named
>> __rnull_mod_irq_mode.
>>
>>
>> Now what to do about this. For the second error (the one related to
>> `pin_init`), I could create a patch that fixes it by adding the suffix
>> `_guard` to those let bindings, preventing the issue. Not sure if we
>> need that though, since it will not get rid of the first issue.
> 
> I think that is a good idea 👍

Will do that.

> 
>>
>> For the first issue, I think there is no other way than to use a
>> different name for either the field or the constant. Since constants are
>> usually named using screaming snake case, I think it should be renamed.
>> I believe your reason for using a snake case name is that these names
>> are used directly as the names for the parameters when loading the
>> module and there the convention is to use snake case, right?
>> In that case I think we could expect people to write the screaming snake
>> case name in rust and have it automatically be lower-cased by the
>> `module!` macro when it creates the names that the parameters are shown
>> with.
> 
> I was thinking about putting the parameters in a separate name space,
> but making them screaming snake case is also a good idea. So it would
> be `module_parameters::IRQ_MODE` to access the parameter with the name
> `irq_mode` exposed towards the user. Developers can always opt in to bringing
> the symbols into scope with a `use`.

I really like the idea of putting them in a module. At the very first
glance at the usage, I thought "where does this come from?!". So having
`module_parameters` in front is really valuable.

-- 
Cheers,
Benno

Powered by blists - more mailing lists