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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240418.223508.1645077134421913977.fujita.tomonori@gmail.com>
Date: Thu, 18 Apr 2024 22:35:08 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: gregkh@...uxfoundation.org
Cc: fujita.tomonori@...il.com, netdev@...r.kernel.org, andrew@...n.ch,
 rust-for-linux@...r.kernel.org, tmgross@...ch.edu, mcgrof@...nel.org,
 russ.weight@...ux.dev
Subject: Re: [PATCH net-next v1 3/4] rust: net::phy support Firmware API

Hi,

On Thu, 18 Apr 2024 15:07:19 +0200
Greg KH <gregkh@...uxfoundation.org> wrote:

> On Thu, Apr 18, 2024 at 09:51:08PM +0900, FUJITA Tomonori wrote:
>> >> diff --git a/rust/kernel/net/phy.rs b/rust/kernel/net/phy.rs
>> >> index 421a231421f5..095dc3ccc553 100644
>> >> --- a/rust/kernel/net/phy.rs
>> >> +++ b/rust/kernel/net/phy.rs
>> >> @@ -9,6 +9,51 @@
>> >>  use crate::{bindings, error::*, prelude::*, str::CStr, types::Opaque};
>> >>  
>> >>  use core::marker::PhantomData;
>> >> +use core::ptr::{self, NonNull};
>> >> +
>> >> +/// A pointer to the kernel's `struct firmware`.
>> >> +///
>> >> +/// # Invariants
>> >> +///
>> >> +/// The pointer points at a `struct firmware`, and has ownership over the object.
>> >> +pub struct Firmware(NonNull<bindings::firmware>);
>> >> +
>> >> +impl Firmware {
>> >> +    /// Loads a firmware.
>> >> +    pub fn new(name: &CStr, dev: &Device) -> Result<Firmware> {
>> >> +        let phydev = dev.0.get();
>> > 
>> > That's risky, how do you "know" this device really is a phydev?
>> 
>> That's guaranteed. The above `Device` is phy::Device.
> 
> How are we supposed to know that from reading this diff?  I think you
> all need to work on naming things better, as that's going to get _VERY_
> confusing very quickly.

I guess that usually a path to a module prevent confusion. For
example, a MAC driver could look like:

fn probe(dev: &mut pci::Device, _: pci::DeviceId) -> Result {
    let netdev = net::Device::new()?;
    let phydev = phy::Device::new()?;
    ...

    Ok(())
}

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ