On Wed, Aug 19, 2026 at 12:56 AM Yury Norov <[email protected]> wrote: > > If there's something more complicated... Let's wait for at least one > real test like that, and not speculate on non-existing cases.
I asked because the issue is that this enforces a policy early on, i.e. if a user happens to need it, then they will have to dive into the implementation to change it or, likely, work around it or assume they shouldn't do that. In other words, there is a cost to enforce something too early on. So it is a balance, depending on what we expect, which is why I asked David about his experience here. > This series begins with "enforce", so it's not about being nice. The > generic kernel tries to save every single bit of memory and nanosecond > of runtime. That's a secret of Linux success IMO. It is great to save bits and nanoseconds, but KUnit is explicitly not meant for production. > pay for the functionality they don't need. In Rust, before e74b7a3f5a > there was no way to throw the tests out. And even after that, we still > have such tests. False, you could disable KUnit (or make it `m`) -- which is what you are supposed to do in production. So, no, we were not bloating every Rust-enabled kernel out there with tests. > This is not a coding style, it's a factual error. So it should be > caught at compile time as an explicit error. Klint and lints in general are not just for coding style. And lints are also compile-time, and they can stop the build too. Cheers, Miguel
