[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <669d8fba-f6bb-4dc8-a06b-752fb83902b4@lunn.ch>
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