Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220805022940.1637978-1-yury.norov@gmail.com>
In-Reply-To: <20220805022940.1637978-1-yury.norov@gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun, 7 Aug 2022 17:12:33 -0700
Message-ID: <CAHk-=wiEVFpiC5M1-zo9Q47uwP+XaCv2rVXan51Ot7L=UXMs7A@mail.gmail.com>
Subject: Re: [GIT PULL] Bitmap patches for v6.0-rc1
To:     Yury Norov <yury.norov@gmail.com>
Cc:     linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Aug 4, 2022 at 7:29 PM Yury Norov <yury.norov@gmail.com> wrote:
>
>   https://github.com/norov/linux.git/ tags/bitmap-6.0-rc1

Grr.

So I delayed this because I was anticipating pain, but it was worse
than expected.

I think I've sorted things out, but part of sorting things out was to
just basically undo this:

>       lib/bitmap: change type of bitmap_weight to unsigned long

which just was pointless and the explanation for it didn't match what it did.

The explanation was "unsigned makes sense". Ok.

But what it *did* was not to make the return value unsigned, but to
also expand it from "int" to "long".

That did *not* make sense, and caused pointless changes to printf strings.

And - surprise surprise - new users had come in since, so there would
have been even *more* pointless changes to printf strings just to
resolve those.

So I basically undid almost all of it. I did leave the "unsigned"
part, but removed the "long" part, so at least the printf strings
noise didn't happen.

That still caused the type clash in the 'min()' in the
mellanox/mlx4/fw.c file, but at least I couldn't find any new cases of
that pattern, so it seemed acceptable.

Can bitmap sizes in theory be "unsigned long" bits and thus have
"weight" not fit in "int"? Yes. But it's not a realistic concern, I
feel, and I really really didn't want to deal with this pointless
churn.

And honestly, this was enough churn that I seriously just considered
throwing the whole pull request away.  And I feel like I will have to
do a few other architecture tests too before I actually push this out,
so I may end up still doing that if that shows something else wrong.

So for any future pull requests, please

 (a) make them more targeted

 (b) avoids things like that return value change that clearly was just
churn and affected random files in the tree

because right now I'm left with a "never again" feeling about this all.

                Linus