[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wg3djFJMeN3L_zx3P-6eN978Y1JTssxy81RhAbxB==L8Q@mail.gmail.com>
Date: Wed, 13 Mar 2024 13:47:59 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kent Overstreet <kent.overstreet@...ux.dev>, "Darrick J. Wong" <djwong@...nel.org>
Cc: linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs updates for 6.9
On Tue, 12 Mar 2024 at 18:10, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
>
> Hi Linus, few patches for you - plus a simple merge conflict with VFS
> changes:
The conflicts are trivial.
The "make random bcachefs code be a library function" stuff I looked
at, decided is senseless, and ended up meaning that I'm not pulling
this without a lot more explanation (and honestly, I don't think the
explanations would hold water).
That "stdio_redirect_printf()" and darray_char stuff is just
horrendous interfaces with no explanations. The interfaces are
disgusting.
Keep it in your own code where it belongs, don't try to make it some
generic library thing.
And if you *do* make it a library thing, it needs to be
(a) much more explained
(b) have much saner naming, and fewer disgusting and completely
nonsensical interfaces ("DARRAY()").
And no, finding one other filesystem to share this kind of code is not
sufficient to try to claim it's a sane interface and sane naming.
But the main dealbreaker is the insane math.
And dammit, we talked about the idiotic "mean and variance" garbage
long ago. It was wrong back then, it's *still* wrong.
You didn't explain why it couldn't use the *much* simpler MAD (median
absolute deviation) instead of using variance.
That bad decision directly results in that pointless use of overly
complex 128-bit math.
I called it insanely over-engineered back then, and as far as I can
tell, absolutely *NOTHING* has changed apart from some slight type
name details.
As long as you made it some kind of bcachefs-only thing, I don't mind.
But now you're trying to push this garbage as some kind of generic
library code that others would use, and that immediately means that I
*do* mind insanely overengineered interfaces.
The time_stats stuff otherwise looks at leask like a sane interface
with names and uses, but the use of that horrendous infrastructure
scuttles it.
Linus
Powered by blists - more mailing lists