[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DDE1K39EUXQK.17AAVZXFZ4KEQ@kernel.org>
Date: Thu, 09 Oct 2025 21:34:04 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Yury Norov" <yury.norov@...il.com>
Cc: "Alexandre Courbot" <acourbot@...dia.com>, "Joel Fernandes"
<joelagnelf@...dia.com>, "Jesung Yang" <y.j3ms.n@...il.com>, "Miguel Ojeda"
<ojeda@...nel.org>, "Alex Gaynor" <alex.gaynor@...il.com>, "Boqun Feng"
<boqun.feong@...il.com>, "Gary Guo" <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>, "Benno Lossin"
<lossin@...nel.org>, "Andreas Hindborg" <a.hindborg@...nel.org>, "Alice
Ryhl" <aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>,
<nouveau@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>,
<rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH RFC v2 3/3] gpu: nova-core: use BoundedInt
On Thu Oct 9, 2025 at 8:28 PM CEST, Yury Norov wrote:
> On Thu, Oct 09, 2025 at 07:18:33PM +0200, Danilo Krummrich wrote:
>> On Thu Oct 9, 2025 at 6:40 PM CEST, Yury Norov wrote:
>> > On Thu, Oct 09, 2025 at 09:37:10PM +0900, Alexandre Courbot wrote:
>> >> Use BoundedInt with the register!() macro and adapt the nova-core code
>> >> accordingly. This makes it impossible to trim values when setting a
>> >> register field, because either the value of the field has been inferred
>> >> at compile-time to fit within the bounds of the field, or the user has
>> >> been forced to check at runtime that it does indeed fit.
>> >
>> > In C23 we've got _BitInt(), which works like:
>> >
>> > unsigned _BitInt(2) a = 5; // compile-time error
>> >
>> > Can you consider a similar name and syntax in rust?
>>
>> Rust is a different language and has its own syntax, I think we should not try
>> to use C syntax instead.
>
> Up to you guys. But having in mind that C is the only language that
> really works for system engineering, I would rather consider to stay
> in line with it on semantic level.
I think you asked about syntax above; semantically it is (and should be) exactly
the same.
> If your goal is to make rust adopted by system engineers, you may
> want to make your language somewhat familiar to what people already
> know.
The goal is to add support for Rust in the Linux kernel; to adapt its advanced
type system features offering compile time checked lifetime and ownership
semantics leading to better memory safety and more compile time validation
overall.
In general I think we should stay as close to existing patterns as possible,
i.e. consistency does matter.
However, sometimes it is necessary to break with existing patterns and design
things slightly different to take full advantage of the capabilities we get from
the language (BoundedInt / BitInt is not one of those).
In other words, introducing a new language with capabilities that solve real
problems is pointless if we subsequently limit ourselfs to "what people already
know" for people who haven't been in touch with the language before.
Powered by blists - more mailing lists