[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANiq72kMfL08r2fJstcfXs3ruzCGTPUkXpWi7hVm5=N9XbuD5w@mail.gmail.com>
Date: Wed, 11 Jan 2023 16:23:44 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Martin Rodriguez Reboredo <yakoyoku@...il.com>
Cc: Eric Curtin <ecurtin@...hat.com>, linux-kernel@...r.kernel.org,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Neal Gompa <neal@...pa.dev>, bpf@...r.kernel.org,
rust-for-linux@...r.kernel.org,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Jiri Olsa <jolsa@...nel.org>, Yonghong Song <yhs@...com>
Subject: Re: [PATCH v2] scripts: Exclude Rust CUs with pahole
On Wed, Jan 11, 2023 at 4:02 PM Martin Rodriguez Reboredo
<yakoyoku@...il.com> wrote:
>
> From my POV I don't like this way due to it being set regardless whether
> or not you are building the kernel with Rust. Though, because it doesn't
> affect non `CONFIG_RUST` builds, I _think_ it won't hurt if we use that
> way for now. Gonna send v3.
One advantage (in general, i.e. not talking about this case in
particular) of having something always done is that it is one less
moving part, so less complexity, everyone will test it all the time,
etc.
So if it is not expected to hurt, but it does for an unknown reason,
then it would be nice to know as soon as possible, regardless of
whether it is gated under `CONFIG_RUST` or not.
Of course, it can always happen that something changes over time, and
thus it may start to hurt in the future only, and therefore breaking
everybody instead of a subset of people. But then again, the sooner we
would know about that unexpected change, the better; especially since
the goal is to eventually get to a point where `CONFIG_RUST` can start
to be routinely enabled by common configurations etc.
Cheers,
Miguel
Powered by blists - more mailing lists