Re: [PATCH v3 2/2] rust: workqueue: add creation of workqueues

[Philipp Stanner]

On Sun, 2026-03-01 at 11:55 +0000, Alice Ryhl wrote:
> On Sat, Feb 28, 2026 at 03:43:02PM +0100, Danilo Krummrich wrote:
> > On Sat Feb 28, 2026 at 1:59 PM CET, Alice Ryhl wrote:
> > > On Fri, Feb 27, 2026 at 08:23:44PM +0100, Danilo Krummrich wrote:
> > > > On Fri Feb 27, 2026 at 8:05 PM CET, Alice Ryhl wrote:
> > > > > On Fri, Feb 27, 2026 at 04:30:59PM +0100, Danilo Krummrich wrote:
> > > > > > On Fri Feb 27, 2026 at 3:53 PM CET, Alice Ryhl wrote:
> > > > > > > +    #[inline]
> > > > > > > +    pub fn max_active(mut self, max_active: u32) -> Builder {
> > > > > > > +        self.max_active = i32::try_from(max_active).unwrap_or(i32::MAX);
> > > > > > 
> > > > > > The workqueue code prints a warning for max_active >  WQ_MAX_ACTIVE. Maybe use
> > > > > > debug_assert()?
> > > > > 
> > > > > What's wrong with just making use of the C-side warning?
> > > > 
> > > > IIRC, we have the same pattern in other Rust code that we use debug_assert()
> > > > when a value got clamped, e.g. in udelay().
> > > 
> > > In udelay(), the clamping happens on the Rust side, so it makes sense
> > > that Rust is the one to warn about it.
> > > 
> > > Here, the clamping happens in C code. To warn about it, I'd have to
> > > duplicate the existing C-side check to clamp in Rust.
> > 
> > That's fair, although I also think that it is not unreasonable. Given that this
> > uses the builder pattern, I think it would be nice to ensure that nothing
> > "invalid" can be built in the first place.
> > 
> > Maybe we can use a bounded integer?
> 
> Bounded integers allow zero, which is also illegal.
> 
> I think it's a bit much honestly.


My two cents here would be too that it's more elegant to just leverage
the C side's warning.

P.