On Mon, 27 Nov 2023 at 08:50, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
>
> Yes, doing it without specific annotations seems like a pain. I did a
> little prototype with the existing sparse __nocast for one xfs type that
> is not very heavily used, and it actually worked pretty good.
>
> The major painpoint is that 0 isn't treated special, but with that
> fixed the amount of churn is mangable.
I would suggest trying to just treat "__bitwise" as the "nocast" type.
And note that doing a
typedef uXX __bitwise new_integer_type;
will make a *specific* new integer type that is only compatible with
itself (so not other bitwise types).
Of course, that only works if you are then willing to just use
accessor functions when you actually want to do arithmetic on the
values. If you use a *lot* of arithmetic - as opposed to just passing
values around - it is too painful.
> The next big thing is our stupid 64-bit divison helpers (do_div & co),
> which require helpers to do that case. I'm actually kinda tempted to
> propose that we drop 32-bit support for xfs to get rid of that and a
> lot of other ugly things because of do_div. That is unless we can
> finally agree that the libgcc division helpes might not be great but
> good enough that we don't want to inflict do_div on folks unless they
> want to optize that case, which would be even better.
>
> Linus, any commens on that?
Some architectures do that, but honestly, we've had *horrendous*
numbers of cases where people did 64x64 divisions without ever
realizing what they did. Having it cause compile failures on x86 -
even if it silently works elsewhere - means that they do get caught
fairly quickly.
Just go to lore, and search for "__divdi3". You will find *tons* of
kernel test robot reports for completely idiotic cases that then never
get to me because of this.
IOW, you may not see it in the resulting kernel, but the reason you
don't see it is *exactly* because we require that do_div() dance for
64-bit divides.
The least one I see is literally from less than a week ago, when media
code tried to do this:
i = v / (1LL << fraction_bits);
without realizing that a signed 64-bit division is truly *horrendous* here.
So you may never see this, but it's a *constant* churn, and we really
are better for it. It's not some historical artifact, it's a "the
kernel test robot finds stuff weekly".
Linus
