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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZXnmGzcdhDr0YQSa@Boquns-Mac-mini.home>
Date: Wed, 13 Dec 2023 09:12:59 -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 08:43:09AM -0800, Boqun Feng wrote:
> 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?

s/doesn't//

> Am I missing something here?
> 
> Regards,
> Boqun
> 
> > 	Andrew
> >