netdev - Re: [PATCH net-next v10 1/4] rust: core abstractions for network PHY drivers

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]

Date: Wed, 13 Dec 2023 08:43:09 -0800
From: Boqun Feng <boqun.feng@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, alice@...l.io,
	netdev@...r.kernel.org, rust-for-linux@...r.kernel.org,
	tmgross@...ch.edu, miguel.ojeda.sandonis@...il.com,
	benno.lossin@...ton.me, wedsonaf@...il.com, aliceryhl@...gle.com
Subject: Re: [PATCH net-next v10 1/4] rust: core abstractions for network PHY
 drivers

On Wed, Dec 13, 2023 at 11:24:03AM +0100, Andrew Lunn wrote:
> > > The C side people read the Rust code before changing the C code? Let's
> > > see. 
> > > 
> > 
> > Hmm... I usually won't call someone "C side people". I mean, the project
> > has C part and Rust part, but the community is one.
> > 
> > In case of myself, I write both C and Rust, if I'm going to change some
> > C side function, I may want to see the usage at Rust side, especially
> > whether my changes could break the safety, and safety comments may be
> > important.
> 
> While i agree with your sentiment, ideally we want bilingual
> developers, in reality that is not going to happen for a long time. I
> could be wrong, but i expect developers to be either C developers, or
> Rust developers. They are existing kernel developers who know C, or
> Rust developers who are new to the kernel, and may not know much C. So

Sorry, I cannot agree with you. Why do we try to divide the community in
two parts? In fact, I keep telling people who want to contribute
Rust-for-Linux that one way to contribute is trying to do some C code
changes first to get familiar with the subsystem and kernel development.

The sentence from Tomo really read like: I don't want to put this
information here, since I don't think anyone would use it. Why do we
want to shutdown the door for more people to collaborate, really, why?
The only downside here is that Tomo needs to maintain a few more lines
of comments. Also the comment is not a random comment, it's the safety
comment, please see below..

> we should try to keep that in mind.
> 
> I personally don't think i have enough Rust knowledge to of even
> reached the dangerous stage. But at least the hard part with Rust
> seems to be the comments, not the actual code :-(
> 

Well, a safety comment is a basic part of Rust, which identifies the
safe/unsafe boundary (i.e. where the code could go wrong in memory
safety) and without that, the code will be just using Rust syntax and
grammar. Honestly, if one doesn't try hard to identify the safe/unsafe
boundaries, why do they try to use Rust? Unsafe Rust is harder to write
than C, and safe Rust is pointless without a clear safe/unsafe boundary.
Plus the syntax is not liked by anyone last time I heard ;-)

Having a correct safety comment is really the bottom line. Without that,
it's just bad Rust code, which I don't think netdev doesn't want either?
Am I missing something here?

Regards,
Boqun

> 	Andrew
>