Re: [PATCH v2 0/3] Rust abstractions for network PHY drivers

From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: FUJITA Tomonori <fujita.tomonori@gmail.com>,
	netdev@vger.kernel.org,  rust-for-linux@vger.kernel.org,
	greg@kroah.com,  Wedson Almeida Filho <wedsonaf@gmail.com>
Subject: Re: [PATCH v2 0/3] Rust abstractions for network PHY drivers
Date: Mon, 9 Oct 2023 14:39:08 +0200	[thread overview]
Message-ID: <CANiq72m+hGUyok5ex98rDMWQpoGC+fMn1hxk6ScLUjhBu-G72A@mail.gmail.com> (raw)
In-Reply-To: <6aac66e0-9cbd-4a7b-91e6-ea429dbe6831@lunn.ch>

On Fri, Oct 6, 2023 at 2:54 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> This is described here, along with other useful hits for working with
> netdev.
>
> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

Off-topic suggestion: the `.rst` file could be linked as the `P:`
field in `MAINTAINERS`, perhaps with some tweaks.

> I don't know if it made the wrong decision based on the missing tag,
> or it simply does not know what to do with Rust yet.

How does it usually determine the tree otherwise (if the tree is not
in the subject)?

> There is also the question of how we merge this. Does it all come
> through netdev? Do we split the patches, the abstraction merged via
> rust and the rest via netdev? Is the Kconfig sufficient that if a tree
> only contains patches 2 and 3 it does not allow the driver to be
> enabled?

Ideally, everything goes through the subsystem's tree whenever they
feel ready to do so. The idea is that maintainers get involved and
handle their Rust code as any other code. Trees like Kbuild, KUnit and
Workqueue have started taking things, for instance, which is great
(and we appreciate it).

Having said that, I would recommend caution -- I would wait until a
few more people from the Rust subsystem give their `Reviewed-by`. In
particular, I would wait until Wedson has given it another look at
least, since he has had the most experience developing networking
abstractions.

I mention this because what we are trying to achieve with the Rust
abstractions is not just functional equivalence to the C side, but
also to make them "sound". In Rust, "sound" means the safe APIs cannot
possibly introduce UB on their own.

Moreover, as I said elsewhere, I do not agree with the
`--rustified-enum` change in the series, given the UB risk (see the
previous paragraph). If we really want to go with that, then we should
be very explicit about the fact that we are placing an assumption on
the C side here.

Cheers,
Miguel