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.>> regs::NV_PFALCON_FALCON_DMATRFBASE1::default() >> - .set_base((dma_start >> 40) as u16) >> + .try_set_base(dma_start >> 40)? >> .write(bar, &E::ID); > > Does it mean that something like the following syntax is possible? > > regs::NV_PFALCON_FALCON_DMATRFBASE1::default() > .try_set_base1(base1 >> 40)? // fail hereNote that try_set_base1() returns a Result [1], which is handled immediately by the question mark operator [2]. I.e. if try_set_base1() returns an error it is propagated to the caller right away without executing any of the code below.> .try_set_base2(base2 >> 40)? // skip > .write(bar, &E::ID) else { pr_err!(); return -EINVAL }; > > This is my main concern: Rust is advertised a as runtime-safe language > (at lease safer than C), but current design isn't safe against one of > the most common errors: type overflow.Where do you see a potential runtime overflows in the register!() code? [1] https://rust.docs.kernel.org/kernel/error/type.Result.html [2] https://doc.rust-lang.org/reference/expressions/operator-expr.html?highlight=question%20mark#the-question-mark-operator
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. 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.> >> regs::NV_PFALCON_FALCON_DMATRFBASE1::default() > >> - .set_base((dma_start >> 40) as u16) > >> + .try_set_base(dma_start >> 40)? > >> .write(bar, &E::ID); > > > > Does it mean that something like the following syntax is possible? > > > > regs::NV_PFALCON_FALCON_DMATRFBASE1::default() > > .try_set_base1(base1 >> 40)? // fail here > > Note that try_set_base1() returns a Result [1], which is handled immediately by > the question mark operator [2]. I.e. if try_set_base1() returns an error it is > propagated to the caller right away without executing any of the code below.Thanks for the links. I am definitely the very beginning on the learning curve for this.> > .try_set_base2(base2 >> 40)? // skip > > .write(bar, &E::ID) else { pr_err!(); return -EINVAL }; > > > > This is my main concern: Rust is advertised a as runtime-safe language > > (at lease safer than C), but current design isn't safe against one of > > the most common errors: type overflow. > > Where do you see a potential runtime overflows in the register!() code?Assuming base is 10-bit, let ret = some_c_wrapper() // 0..1024 or -EINVAL regs::NV_PFALCON_FALCON_DMATRFBASE1::default() .try_set_base1(ret) Or maybe I misunderstood the question, because if there's no possibility to overflow a field, what for the .try_set_xxx() is needed at all?> [1] https://rust.docs.kernel.org/kernel/error/type.Result.html > [2] https://doc.rust-lang.org/reference/expressions/operator-expr.html?highlight=question%20mark#the-question-mark-operator
On 10/9/2025 2:28 PM, Yury Norov wrote: [..]>>>> regs::NV_PFALCON_FALCON_DMATRFBASE1::default() >>>> - .set_base((dma_start >> 40) as u16) >>>> + .try_set_base(dma_start >> 40)? >>>> .write(bar, &E::ID); >>> >>> Does it mean that something like the following syntax is possible? >>> >>> regs::NV_PFALCON_FALCON_DMATRFBASE1::default() >>> .try_set_base1(base1 >> 40)? // fail here >> >> Note that try_set_base1() returns a Result [1], which is handled immediately by >> the question mark operator [2]. I.e. if try_set_base1() returns an error it is >> propagated to the caller right away without executing any of the code below. > > Thanks for the links. I am definitely the very beginning on the > learning curve for this. > >>> .try_set_base2(base2 >> 40)? // skip >>> .write(bar, &E::ID) else { pr_err!(); return -EINVAL }; >>> >>> This is my main concern: Rust is advertised a as runtime-safe language >>> (at lease safer than C), but current design isn't safe against one of >>> the most common errors: type overflow. >> >> Where do you see a potential runtime overflows in the register!() code? > > Assuming base is 10-bit, > > let ret = some_c_wrapper() // 0..1024 or -EINVAL > regs::NV_PFALCON_FALCON_DMATRFBASE1::default() > .try_set_base1(ret) > > Or maybe I misunderstood the question, because if there's no possibility > to overflow a field, what for the .try_set_xxx() is needed at all?Because 'ret' is a value determined at runtime in this example, there is no way for the compiler to know that ret will fit into the bounded int, at compile time. So the "try_" means it is runtime checked and validated (via return of Result). Sure it may well not fail, but the compiler doesn't know that. Thanks.
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.