Re: [PATCH net-next v7 1/5] rust: core abstractions for network PHY drivers
From: Benno Lossin <hidden>
Date: 2023-10-30 08:37:47
Also in:
rust-for-linux
From: Benno Lossin <hidden>
Date: 2023-10-30 08:37:47
Also in:
rust-for-linux
On 29.10.23 18:32, Andrew Lunn wrote:
quoted
The current code is fine from Rust perspective because the current code copies phy_driver on stack and makes a reference to the copy, if I undertand correctly. It's not nice to create an 500-bytes object on stack. It turned out that it's not so simple to avoid it.Does it also copy the stack version over the 'real' version before exiting? If not, it is broken, since modifying state in phy_device is often why the driver is called. But copying the stack version is also broken, since another thread taking the phydev->lock is going to get lost from the linked list of waiters.
It does not copy the stack version over the original. Since we only read the `link` field in the discussed function and we hold the lock, it should not get modified, right? So from a functional viewpoint there is no issue. (Aside from increased stack size and the data race issue etc.)
Taking a copy of the C structure does seem very odd, to me as a C programmer.
It is also odd in Rust. -- Cheers, Benno