On Tue, 19 Mar 2024 at 07:12, Heiko Carstens <hca@xxxxxxxxxxxxx> wrote:
>
> - Add new bitwise types and helper functions and use them in s390 specific
> drivers and code to make it easier to find virtual vs physical address
> usage bugs.
Hmm. Because you still want to be able to do arithmetic on them, this
is really what "__nocast" should be used for rather than "__bitwise".
__bitwise was intended (as the name implies) for things that can only
be mixed bitwise with similar types. It was _mainly_ for big-endian vs
little-endian marking, where it's actually perfectly fine to do
bitwise operations on two big-endian values without ever translation
them to "cpu endianness", but you can't for example do normal
arithmetic on them.
So __bitwise has those very specific rules that seem odd until you
realize what the reason for them are.
In contrast, your types actually *would* be fine with arithmetic and
logical operations being done on them, and that is what "__nocast"
really was meant to be.
But we basically never had much use for __nocast in the kernel, and
largely as a result __nocast was never fleshed out to work very well
(and it gets lost *much* too easily), so __bitwise it is.
Oh well.
It looks like it's not a lot of arithmetic you want to allow anyway,
so I guess the fact that __bitwise forces you to do some silly helper
functions for that isn't too much of an issue.
Linus
