netdev - Re: [PATCH net-next] rust: phy: use VTABLE_DEFAULT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4573a237-dd18-4ea0-8de4-8b465eb856c7@lunn.ch>
Date: Thu, 25 Jan 2024 18:42:05 +0100
From: Andrew Lunn <andrew@...n.ch>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: netdev@...r.kernel.org, rust-for-linux@...r.kernel.org,
	tmgross@...ch.edu
Subject: Re: [PATCH net-next] rust: phy: use VTABLE_DEFAULT_ERROR

On Thu, Jan 25, 2024 at 10:45:02AM +0900, FUJITA Tomonori wrote:
> Since 6.8-rc1, using VTABLE_DEFAULT_ERROR for optional functions
> (never called) in #[vtable] is the recommended way.
> 
> Note that no functional changes in this patch.
> 
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@...il.com>
> ---
>  rust/kernel/net/phy.rs | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/rust/kernel/net/phy.rs b/rust/kernel/net/phy.rs
> index 203918192a1f..96e09c6e8530 100644
> --- a/rust/kernel/net/phy.rs
> +++ b/rust/kernel/net/phy.rs
> @@ -580,12 +580,12 @@ pub trait Driver {
>  
>      /// Issues a PHY software reset.
>      fn soft_reset(_dev: &mut Device) -> Result {
> -        Err(code::ENOTSUPP)
> +        kernel::build_error(VTABLE_DEFAULT_ERROR)
>      }

Dumb question, which i should probably duckduckgo myself.

Why is it called VTABLE_DEFAULT_ERROR and not
VTABLE_NOT_SUPPORTED_ERROR?

Looking through the C code my guess would be -EINVAL would be the
default, or maybe 0.

The semantics of ENOTSUPP can also vary. Its often not an actual
error, it just a means to indicate its not supported, and the caller
might decide to do something different as a result. One typical use in
the network stack is offloading functionality to hardware.
e.g. blinking the LEDs on the RJ45 connected. The driver could be
asked to blink to show activity of a received packet. Some hardware
can only indicate activity for both receive and transmit, so the
driver would return -EOPNOTSUPP. Software blinking would then be used
instead of hardware blinking.

	 Andrew