Re: [PATCH net-next v5 1/5] rust: core abstractions for network PHY drivers

[Benno Lossin <benno.lossin@proton.me>]

On 19.10.23 16:42, FUJITA Tomonori wrote:
>>>>> +/// Registration structure for a PHY driver.
>>>>> +///
>>>>> +/// # Invariants
>>>>> +///
>>>>> +/// The `drivers` slice are currently registered to the kernel via `phy_drivers_register`.
>>>>> +pub struct Registration {
>>>>> +    drivers: &'static [DriverType],
>>>>> +}
>>>>
>>>> You did not reply to my suggestion [2] to remove this type,
>>>> what do you think?
>>>>
>>>> [2]: https://lore.kernel.org/rust-for-linux/85d5c498-efbc-4c1a-8d12-f1eca63c45cf@proton.me/
>>>
>>> I tried before but I'm not sure it simplifies the implementation.
>>>
>>> Firstly, instead of Reservation, we need a public function like
>>>
>>> pub fn phy_drivers_register(module: &'static crate::ThisModule, drivers: &[DriverVTable]) -> Result {
>>>       to_result(unsafe {
>>>           bindings::phy_drivers_register(drivers[0].0.get(), drivers.len().try_into()?, module.0)
>>>       })
>>> }
>>>
>>> This is because module.0 is private.
>>
>> Why can't this be part of the macro?
> 
> I'm not sure I correctly understand what you suggest so you meant the following?
> 
>      (drivers: [$($driver:ident),+], device_table: [$($dev:expr),+], $($f:tt)*) => {
>          struct Module {
>               _drv:  [
>                  ::kernel::net::phy::DriverVTable;
>                  $crate::module_phy_driver!(@count_devices $($driver),+)
>              ],
>          }
>          unsafe impl Sync for Module {}
> 
>          $crate::prelude::module! {
>              type: Module,
>              $($f)*
>          }
> 
>          impl ::kernel::Module for Module {
>              fn init(module: &'static ThisModule) -> Result<Self> {
>                  let drv = [
>                      $(::kernel::net::phy::create_phy_driver::<$driver>()),+
>                  ];
>                  ::kernel::error::to_result(unsafe {
>                      ::kernel::bindings::phy_drivers_register(drv[0].0.get(), drv.len().try_into()?, module.0)

You can just do this (I omitted the `::kernel::` prefix for
readability, if you add this in the macro, please include it):

     // CAST: `DriverVTable` is `repr(transparent)` and wrapping `bindings::phy_driver`.
     let ptr = drv.as_mut_ptr().cast::<bindings::phy_driver>();
     let len = drv.len().try_into()?;
     // SAFETY: ...
     to_result(unsafe { bindings::phy_drivers_register(ptr, len, module.0) })?;

>                  })?;
> 
>                  Ok(Module {
>                      _drv: drv,
>                  })
>              }
>          }
> 
> Then we got the following error:
> 
> error[E0616]: field `0` of struct `DriverVTable` is private
>    --> drivers/net/phy/ax88796b_rust.rs:12:1
>       |
>       12 | / kernel::module_phy_driver! {
>       13 | |     drivers: [PhyAX88772A, PhyAX88772C, PhyAX88796B],
>       14 | |     device_table: [
>       15 | |         DeviceId::new_with_driver::<PhyAX88772A>(),
>       ...  |
>       22 | |     license: "GPL",
>       23 | | }
>          | |_^ private field
> 	   |
> 	      = note: this error originates in the macro
> 	      `kernel::module_phy_driver` (in Nightly builds, run with
> 	      -Z macro-backtrace for more info)
> 
> error[E0616]: field `0` of struct `kernel::ThisModule` is private
>    --> drivers/net/phy/ax88796b_rust.rs:12:1
>       |
>       12 | / kernel::module_phy_driver! {
>       13 | |     drivers: [PhyAX88772A, PhyAX88772C, PhyAX88796B],
>       14 | |     device_table: [
>       15 | |         DeviceId::new_with_driver::<PhyAX88772A>(),
>       ...  |
>       22 | |     license: "GPL",
>       23 | | }
>          | |_^ private field
> 
> 
>>> Also if we keep DriverVtable.0 private, we need another public function.
>>>
>>> pub unsafe fn phy_drivers_unregister(drivers: &'static [DriverVTable])
>>> {
>>>       unsafe {
>>>           bindings::phy_drivers_unregister(drivers[0].0.get(), drivers.len() as i32)
>>>       };
>>> }
>>>
>>> DriverVTable isn't guaranteed to be registered to the kernel so needs
>>> to be unsafe, I guesss.
>>
>> In one of the options I suggest to make that an invariant of `DriverVTable`.
>>
>>>
>>> Also Module trait support exit()?
>>
>> Yes, just implement `Drop` and do the cleanup there.
>>
>> In the two options that I suggested there is a trade off. I do not know
>> which option is better, I hoped that you or Andrew would know more:
>> Option 1:
>> * advantages:
>>     - manual creation of a phy driver module becomes possible.
>>     - less complex `module_phy_driver` macro.
>>     - no static variable needed.
>> * disadvantages:
>>     - calls `phy_drivers_register` for every driver on module
>>       initialization.
>>     - calls `phy_drivers_unregister` for every driver on module
>>       exit.
>>
>> Option 2:
>> * advantages:
>>     - less complex `module_phy_driver` macro.
>>     - no static variable needed.
>>     - only a single call to
>>       `phy_drivers_register`/`phy_drivers_unregister`.
>> * disadvantages:
>>     - no safe manual creation of phy drivers possible, the only safe
>>       way is to use the `module_phy_driver` macro.
>>
>> I suppose that it would be ok to call the register function multiple
>> times, since it only is on module startup/shutdown and it is not
>> performance critical.
> 
> I think that we can use the current implantation using Reservation
> struct until someone requests manual creation. I doubt that we will
> need to support such.

I would like to remove the mutable static variable and simplify
the macro.

-- 
Cheers,
Benno