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: Fri, 27 Oct 2023 15:00:13 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org,
	rust-for-linux@...r.kernel.org, tmgross@...ch.edu,
	benno.lossin@...ton.me, wedsonaf@...il.com
Subject: Re: [PATCH net-next v7 0/5] Rust abstractions for network PHY drivers

> Do the CI tests support Rust now? Does Tomo's patch pass CI? Looks like
> something we'd like to see (and help).

Its work in progress.

https://patchwork.kernel.org/project/netdevbpf/patch/20231026001050.1720612-6-fujita.tomonori@gmail.com/

These are the current tests we have. You can see it fails two tests. I
would say neither are blockers. netdev does try to stick to 80
character line length, so it would be nice to fix that. The checkpatch
warning about the Kconfig help can also be ignored.

There are currently a few builds performed for each patch, once with
gcc and once with clang/llvm. These use the allmodconfig kernel
configuration, since that generally builds the most code. However,
Rust is not enabled in the configuration. So i submitted a new test,
based on the clang build, which massages the kernel configuration to
actually enable Rust, and to ensure the dependencies are fulfilled to
allow the PHY driver to be enabled, and then enable it. We want the
build with a patch to have equal or less errors and warning from the
toolchain.

Its not clear how long it will take before this new test becomes
active. The build machine does not have a Rust toolchain yet, etc.  To
make up for that, i just build the series myself on my machine, and it
builds cleanly for me.

We are also open to add more tests. You will get more return on
investment if you extend the C=1 checks, since that is used in a lot
more places than networking. But we can add more tests to the
networking CI system, if you can tell us what to test, how to test it,
and how to evaluate the results.

> > likely will be merged. Real problems can be fixed up later, if need
> > be.
> 
> But this doesn't apply to pure API, right? So if some one post a pure
> Rust API with no user, but some tests, and the CI passes, the API won't
> get merged? Even though no review is fine and if API has problems, we
> can fix it later?

There is always a human involved. If a reviewer does not pick up the
missing user, the Maintainer should and reject the patch.

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ