[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <67AB9311-3EDC-44A8-9C7C-ABF2ED6B632C@collabora.com>
Date: Thu, 6 Feb 2025 12:57:30 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Guangbo Cui <2407018371@...com>,
Miguel Ojeda <ojeda@...nel.org>
Cc: a.hindborg@...nel.org,
alex.gaynor@...il.com,
aliceryhl@...gle.com,
benno.lossin@...ton.me,
bjorn3_gh@...tonmail.mco,
boqun.feng@...il.com,
boris.brezillon@...labora.com,
dakr@...nel.org,
gary@...yguo.net,
gregkh@...uxfoundation.org,
linux-kernel@...r.kernel.org,
ojeda@...nel.org,
rafael@...nel.org,
robh@...nel.org,
rust-for-linux@...r.kernel.org,
tmgross@...ch.edu
Subject: Re: [PATCH v6 2/3] rust: io: mem: add a generic iomem abstraction
Btw, Miguel & others,
IMHO, I think we should write a comment about this somewhere in the docs.
When I first came across this issue myself, it took me a while to understand that
the build_error was actually triggering.
That’s because the result is:
```
ERROR: modpost: "rust_build_error" [rust_platform_uio_driver.ko] undefined!
```
When a symbol is undefined, someone would be within their rights to assume that
something is broken in some KConfig somewhere, like this person did. It specifically
doesn’t tell them that the problem is their own code triggering a build_error because
they are misusing an API.
I know that we can’t really provide a message through build_error itself, hence my
suggestion about the docs.
I can send a patch if you agree, it will prevent this confusion from coming up in the
future.
— Daniel
Powered by blists - more mailing lists