[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjd5HML-EuPGH7J8CjWJrbnMhst3NJbcUyt-P0RV649nA@mail.gmail.com>
Date: Mon, 29 Jun 2020 12:23:34 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: linux-arch <linux-arch@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Tony Luck <tony.luck@...el.com>, Will Deacon <will@...nel.org>
Subject: Re: [PATCH 18/41] regset: new method and helpers for it
On Mon, Jun 29, 2020 at 11:28 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> ->get2() takes task+regset+buffer, returns the amount of free space
> left in the buffer on success and -E... on error.
Can we please give it a better name than "get2"?
That's not a great name to begin with, and it's a completely
nonsensical name by the end of this series when you've removed the
original "get" function.
So either:
(a) add one final patch to rename "get2" all back to "get" after you
got rid of the old "get"
(b) or just call it something better to begin with. Maybe just
"get_regset" instead?
I'd prefer (b) just because I think it will be a lot clearer if we
ever end up having old patches forward-ported (or, more likely,
newpatches back-ported), so having a "get" function that changed
semantics but got back the old name sounds bad to me.
Other than that, I can't really argue with the numbers:
41 files changed, 1368 insertions(+), 2347 deletions(-)
looks good to me, and the code seems more understandable.
But I only scanned the individual patches, maybe I missed some other horror.
Linus
Powered by blists - more mailing lists