rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boqun Feng <boqun.feng@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: FUJITA Tomonori <fujita.tomonori@gmail.com>,
	alice@ryhl.io, netdev@vger.kernel.org,
	rust-for-linux@vger.kernel.org, tmgross@umich.edu,
	miguel.ojeda.sandonis@gmail.com, benno.lossin@proton.me,
	wedsonaf@gmail.com, aliceryhl@google.com
Subject: Re: [PATCH net-next v10 1/4] rust: core abstractions for network PHY drivers
Date: Wed, 13 Dec 2023 09:12:59 -0800	[thread overview]
Message-ID: <ZXnmGzcdhDr0YQSa@Boquns-Mac-mini.home> (raw)
In-Reply-To: <ZXnfHbKE3K_J4yul@Boquns-Mac-mini.home>

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
> > 

  reply	other threads:[~2023-12-13 17:13 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-10 23:49 [PATCH net-next v10 0/4] Rust abstractions for network PHY drivers FUJITA Tomonori
2023-12-10 23:49 ` [PATCH net-next v10 1/4] rust: core " FUJITA Tomonori
2023-12-11 14:01   ` Andrew Lunn
2023-12-11 19:49   ` [net-next PATCH] rust: net: phy: Correct the safety comment for impl Sync Boqun Feng
2023-12-11 20:23     ` Boqun Feng
2023-12-11 21:50     ` Alice Ryhl
2023-12-11 23:22       ` Boqun Feng
2023-12-11 23:55         ` FUJITA Tomonori
2023-12-12  9:17           ` Alice Ryhl
2023-12-12 10:36             ` FUJITA Tomonori
2023-12-11 21:46   ` [PATCH net-next v10 1/4] rust: core abstractions for network PHY drivers Alice Ryhl
2023-12-11 23:15     ` FUJITA Tomonori
2023-12-11 23:40       ` Boqun Feng
2023-12-11 23:47         ` FUJITA Tomonori
2023-12-12  0:49           ` Boqun Feng
2023-12-12  1:46             ` FUJITA Tomonori
2023-12-12  2:30               ` Boqun Feng
2023-12-12  4:04                 ` FUJITA Tomonori
2023-12-12  6:11                   ` Boqun Feng
2023-12-12 13:02                     ` FUJITA Tomonori
2023-12-12 17:35                       ` Benno Lossin
2023-12-12 20:23                         ` Boqun Feng
2023-12-12 22:40                           ` Benno Lossin
2023-12-12 23:27                             ` FUJITA Tomonori
2023-12-13  0:02                               ` Benno Lossin
2023-12-12 23:31                           ` FUJITA Tomonori
2023-12-13  0:01                             ` Benno Lossin
2023-12-12 23:01                         ` FUJITA Tomonori
2023-12-12 23:15                           ` Benno Lossin
2023-12-13 10:28                         ` Andrew Lunn
2023-12-13 12:14                           ` Benno Lossin
2023-12-13 10:24                     ` Andrew Lunn
2023-12-13 16:43                       ` Boqun Feng
2023-12-13 17:12                         ` Boqun Feng [this message]
2023-12-13 21:48                         ` Andrew Lunn
2023-12-13 23:40                           ` Benno Lossin
2023-12-13 23:51                             ` Benno Lossin
2023-12-14  9:26                             ` Andrew Lunn
2023-12-13 23:59                           ` Boqun Feng
2023-12-12 12:55                   ` Miguel Ojeda
2023-12-12  9:23       ` Alice Ryhl
2023-12-12 10:56         ` FUJITA Tomonori
2023-12-10 23:49 ` [PATCH net-next v10 2/4] rust: net::phy add module_phy_driver macro FUJITA Tomonori
2023-12-11 14:01   ` Andrew Lunn
2023-12-12 22:52   ` Trevor Gross
2023-12-10 23:49 ` [PATCH net-next v10 3/4] MAINTAINERS: add Rust PHY abstractions for ETHERNET PHY LIBRARY FUJITA Tomonori
2023-12-10 23:49 ` [PATCH net-next v10 4/4] net: phy: add Rust Asix PHY driver FUJITA Tomonori
2023-12-11 14:01   ` Andrew Lunn
2023-12-11 21:52   ` Alice Ryhl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZXnmGzcdhDr0YQSa@Boquns-Mac-mini.home \
    --to=boqun.feng@gmail.com \
    --cc=alice@ryhl.io \
    --cc=aliceryhl@google.com \
    --cc=andrew@lunn.ch \
    --cc=benno.lossin@proton.me \
    --cc=fujita.tomonori@gmail.com \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=wedsonaf@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).