On Tue, Jan 20, 2026 at 03:10:54PM +0000, Lorenzo Stoakes wrote:
> The natural implication of what you're saying is that we can no longer use
> this
> from _anywhere_ because - hey - passing this by value is bad so now
> _everything_
> has to be re-written as:
No, I'm not saying that, I'm saying this specific case where you are
making an accessor to reach an unknown value located on the heap
should be using a pointer as both a matter of style and to simplify
life for the compiler.
> vma_flags_t flags_to_set = mk_vma_flags(<flags>);
>
> if (vma_flags_test(&flags, &flags_to_set)) { ... }
This is quite a different situation, it is a known const at compile
time value located on the stack.
> If it was just changing this one function I'd still object as it makes it
> differ
> from _every other test predicate_ using vma_flags_t but maybe to humour you
> I'd
> change it, but surely by this argument you're essentially objecting to the
> whole
> series?
I only think that if you are taking a heap input that is not of known
value you should continue to pass by pointer as is generally expected
in the C style we use.
And it isn't saying anything about the overall technique in the
series, just a minor note about style.
> I am not sure about this 'idiomatic kernel style' thing either, it feels
> rather
> conjured. Yes you wouldn't ordinarily pass something larger than a register
> size
> by-value, but here the intent is for it to be inlined anyway right?
Well, exactly, we don't normally pass things larger than an interger
by value, that isn't the style, so I don't think it is such a great
thing to introduce here kind of unnecessarily.
The troubles I recently had were linked to odd things like gcov and
very old still supported versions of gcc. Also I saw a power compiler
make a very strange choice to not inline something that evaluated to a
constant.
Jason
