[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20231021.130106.420701850571246291.fujita.tomonori@gmail.com>
Date: Sat, 21 Oct 2023 13:01:06 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: nmi@...aspace.dk
Cc: fujita.tomonori@...il.com, netdev@...r.kernel.org,
rust-for-linux@...r.kernel.org, andrew@...n.ch,
miguel.ojeda.sandonis@...il.com, tmgross@...ch.edu, boqun.feng@...il.com,
wedsonaf@...il.com, benno.lossin@...ton.me, greg@...ah.com
Subject: Re: [PATCH net-next v5 1/5] rust: core abstractions for network
PHY drivers
On Fri, 20 Oct 2023 19:26:50 +0200
"Andreas Hindborg (Samsung)" <nmi@...aspace.dk> wrote:
>> +/// An instance of a PHY driver.
>> +///
>> +/// Wraps the kernel's `struct phy_driver`.
>> +///
>> +/// # Invariants
>> +///
>> +/// `self.0` is always in a valid state.
>> +#[repr(transparent)]
>> +pub struct DriverType(Opaque<bindings::phy_driver>);
>
> I don't like the name `DriverType`. How about `DriverDesciptor` or
> something like that?
Benno suggested DriverVTable. I plan to use that name in the next
version.
>> +
>> + // macro use only
>> + #[doc(hidden)]
>> + pub const fn mdio_device_id(&self) -> bindings::mdio_device_id {
>> + bindings::mdio_device_id {
>> + phy_id: self.id,
>> + phy_id_mask: self.mask.as_int(),
>> + }
>> + }
>
> Would it make sense to move this function to the macro patch?
IMHO, either is fine.
You could say that the function is used only in the macro but also you
could say that this is the method of DeviceId.
Powered by blists - more mailing lists