netdev - Re: [PATCH net-next v3 1/3] 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: Tue, 10 Oct 2023 00:15:36 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: miguel.ojeda.sandonis@...il.com
Cc: fujita.tomonori@...il.com, netdev@...r.kernel.org,
 rust-for-linux@...r.kernel.org, andrew@...n.ch, greg@...ah.com,
 tmgross@...ch.edu, wedsonaf@...il.com
Subject: Re: [PATCH net-next v3 1/3] rust: core abstractions for network
 PHY drivers

On Mon, 9 Oct 2023 16:32:42 +0200
Miguel Ojeda <miguel.ojeda.sandonis@...il.com> wrote:

> On Mon, Oct 9, 2023 at 3:49 PM FUJITA Tomonori
> <fujita.tomonori@...il.com> wrote:
>>
>> We have about two weeks before the merge window opens? It would great
>> if other people could review really soon.
>>
>> We can improve the abstractions after it's merged. This patchset
>> doesn't add anything exported to users. This adds only one driver so
>> the APIs can be fixed anytime.
>>
>> Once it's merged, multiple people can send patches easily, so more
>> scalable.
> 
> I think it is too soon to merge it unless you get some more reviews.
> 
> On the other hand, I agree iterating in-tree is easier.
> 
> If you want to merge it very soon, I would suggest
> considering/evaluating the following:

It's up to PHY maintainers. I prefer that the patchset are merged very
soon. Much easier to improve the code in tree.


>   - Please consider marking the driver as a "Rust reference driver"
> [1] that is not meant to be used (yet, at least) in production. That
> would probably be the best signal, and everybody is clear on the
> expectations.

Of course. I would be very surprised if someone think that a Rust
driver is ready for production because Rust support is an
experiment.

How I can mark the driver as a "Rust reference driver"? Kconfig
description?


>   - Otherwise, please consider marking it as staging/experimental for
> the time being. That allows you to iterate the abstractions at your
> own pace. Of course, it still risks somebody out-of-tree using them,
> but see the next points.
> 
>   - Should fixes to the code be considered actual fixes and sent to
> stable? If we do one of the above, I guess you could simply say the
> code is in development.
> 
>   - Similarly, what about Rust unsoundness issues? We do want to
> consider those as stable-worthy patches even if they may not be "real"
> security issues, and just "potential" ones. We did submit an stable
> patch in the past for one of those.
> 
> [1] https://lore.kernel.org/ksummit/CANiq72=99VFE=Ve5MNM9ZuSe9M-JSH1evk6pABNSEnNjK7aXYA@mail.gmail.com/

If a driver is marked as a reference driver, we don't need to think
about "stable" stuff, right?