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

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

On 20.10.23 21:50, Andrew Lunn wrote:
>> I will try to explain things a bit more.
>>
>> So this case is a bit difficult to figure out, because what is
>> going on is not really a pattern that is used in Rust.
> 
> It is however a reasonably common pattern in the kernel. It stems from
> driver writers often don't understand locking. So the core does the
> locking, leaving the driver writers to just handle the problems of the
> hardware.

I have seen this pattern the first time here, I am sure more experienced
members such as Miguel and Wedson have seen it before.

I am not saying that it is incompatible with Rust, just that it
wouldn't be done like this if it were purely Rust.

> Rust maybe makes locking more of a visible issue, but if driver
> writers don't understand locking, the language itself does not make
> much difference.

I think Rust will make a big difference:
- you cannot access data protected by a lock without locking the
   lock beforehand.
- you cannot forget to unlock a lock.

>> We already have exclusive access to the `phy_device`, so in Rust
>> you would not need to lock anything to also have exclusive access to the
>> embedded `mii_bus`.
> 
> I would actually say its not the PHY drivers problem at all. The
> mii_bus is a property of the MDIO layers, and it is the MDIO layers
> problem to impose whatever locking it needs for its properties.

Since the MDIO layer would provide its own serialization, in Rust
we would not protect the `mdio_device` with a lock. In this case
it could just be a coincidence that both locks are locked, since
IIUC `phy_device` is locked whenever callbacks are called.

> Also, mii_bus is not embedded. Its a pointer to an mii_bus. The phy
> lock protects the pointer. But its the MDIO layer which needs to
> protect what the pointer points to.

Oh I overlooked the `*`. Then it depends what type of pointer that is,
is the `mii_bus` unique or is it shared? If it is shared, then Rust
would also need another lock there.

-- 
Cheers,
Benno