linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-arch <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Tony Luck <tony.luck@intel.com>, Will Deacon <will@kernel.org>
Subject: Re: [PATCH 18/41] regset: new method and helpers for it
Date: Mon, 29 Jun 2020 21:30:28 +0100	[thread overview]
Message-ID: <20200629203028.GB2786714@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAHk-=wjd5HML-EuPGH7J8CjWJrbnMhst3NJbcUyt-P0RV649nA@mail.gmail.com>

On Mon, Jun 29, 2020 at 12:23:34PM -0700, Linus Torvalds wrote:
> On Mon, Jun 29, 2020 at 11:28 AM Al Viro <viro@zeniv.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"

Bad idea, IMO...

>  (b) or just call it something better to begin with. Maybe just
> "get_regset" instead?

<nod>

Frankly, other field names there are also nasty - 'set' is not
fun to grep for, but there are 'n' and 'size' as well.  There's
also 'bias'  and 'align' (both completely unused)...

> 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.

FWIW, there's also ->set() side of that thing.  Tons of boilerplate
in those; I hadn't seriously looked into that part, but I suspect
that "do copyin in the caller, pass the kernel buffer to the
method, always start at offset 0" would also trim a lot of crap.
I'd rather leave that one for later - this series had been painful
enough.

Other things in the same area: conversion of fdpic coredumps to
regset (fairly easy, I've a patch series doing that in the local
tree), conversion of the few remaining non-regset architectures
to regset-based coredump (kill a large chunk of rotting code in
fs/binfmt_elf.c, along with quite a few pieces of old per-arch
coredump helpers), unification of compat ELF (done locally,
mipsn32/mipso32 gone, all compat done via compat_binfmt_elf.c,
x32 horrors sanitized - IMO
#define PRSTATUS_SIZE \
       (test_thread_flag(TIF_X32) \
               ? sizeof(struct compat_elf_prstatus) \
               : sizeof(struct i386_elf_prstatus))
#define SET_PR_FPVALID(S) \
       (*(test_thread_flag(TIF_X32) \
               ? &(S)->pr_fpvalid      \
               : &((struct i386_elf_prstatus *)(S))->pr_fpvalid) = 1)
is much better than
#define PRSTATUS_SIZE(S, R) (R != sizeof(S.pr_reg) ? 144 : 296)
#define SET_PR_FPVALID(S, V, R) \
  do { *(int *) (((void *) &((S)->pr_reg)) + R) = (V); } \
  while (0)
) and a bunch of assorted cleanups that got trimmed from the
regset series...

I'll probably post fdpic and compat series tonight and get
back to uaccess and VFS stuff.

  reply	other threads:[~2020-06-29 20:30 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-29 18:23 [RFC][PATCHSET] regset ->get() rework Al Viro
2020-06-29 18:25 ` [PATCH 01/41] introduction of regset ->get() wrappers, switching ELF coredumps to those Al Viro
2020-06-29 18:25   ` [PATCH 02/41] x86: copy_fpstate_to_sigframe(): have fpregs_soft_get() use kernel buffer Al Viro
2020-06-29 18:25   ` [PATCH 03/41] x86: kill dump_fpu() Al Viro
2020-06-29 18:25   ` [PATCH 04/41] [ia64] sanitize elf_access_gpreg() Al Viro
2020-06-29 18:25   ` [PATCH 05/41] [ia64] teach elf_access_reg() to handle the missing range (r16..r31) Al Viro
2020-06-29 18:25   ` [PATCH 06/41] [ia64] regularize do_gpregs_[gs]et() Al Viro
2020-06-29 18:25   ` [PATCH 07/41] [ia64] access_uarea(): stop bothering with gpregs_[gs]et() Al Viro
2020-06-29 18:25   ` [PATCH 08/41] [ia64] access_uarea(): don't bother with fpregs_[gs]et() Al Viro
2020-06-29 18:25   ` [PATCH 09/41] sparc64: switch genregs32_get() to use of get_from_target() Al Viro
2020-06-29 18:25   ` [PATCH 10/41] sparc32: get rid of odd callers of copy_regset_to_user() Al Viro
2020-06-29 18:25   ` [PATCH 11/41] sparc64: " Al Viro
2020-06-29 18:25   ` [PATCH 12/41] sparc32: get rid of odd callers of copy_regset_from_user() Al Viro
2020-06-29 18:26   ` [PATCH 13/41] sparc64: " Al Viro
2020-06-29 18:26   ` [PATCH 14/41] arm64: take fetching compat reg out of pt_regs into a new helper Al Viro
2020-06-29 18:26   ` [PATCH 15/41] arm64: get rid of copy_regset_to_user() in compat_ptrace_read_user() Al Viro
2020-06-29 18:26   ` [PATCH 16/41] arm64: sanitize compat_ptrace_write_user() Al Viro
2020-06-29 18:26   ` [PATCH 17/41] copy_regset_to_user(): do all copyout at once Al Viro
2020-06-29 18:26   ` [PATCH 18/41] regset: new method and helpers for it Al Viro
2020-06-29 19:23     ` Linus Torvalds
2020-06-29 20:30       ` Al Viro [this message]
2020-06-30 13:25         ` Al Viro
2020-06-30 16:53           ` Linus Torvalds
2020-06-30 19:40             ` Al Viro
2020-06-29 18:26   ` [PATCH 19/41] x86: switch to ->get2() Al Viro
2020-06-29 18:26   ` [PATCH 20/41] powerpc: " Al Viro
2020-06-29 18:26   ` [PATCH 21/41] s390: " Al Viro
2020-06-29 18:26   ` [PATCH 22/41] sparc: " Al Viro
2020-06-30 13:16     ` Al Viro
2020-06-29 18:26   ` [PATCH 23/41] mips: " Al Viro
2020-06-29 18:26   ` [PATCH 24/41] arm64: " Al Viro
2020-06-29 18:26   ` [PATCH 25/41] sh: convert " Al Viro
2020-06-29 18:26   ` [PATCH 26/41] arm: switch " Al Viro
2020-06-29 18:26   ` [PATCH 27/41] arc: " Al Viro
2020-06-29 18:26   ` [PATCH 28/41] ia64: " Al Viro
2020-06-29 18:26   ` [PATCH 29/41] c6x: " Al Viro
2020-06-29 18:26   ` [PATCH 30/41] riscv: " Al Viro
2020-06-29 18:26   ` [PATCH 31/41] openrisc: " Al Viro
2020-06-29 18:26   ` [PATCH 32/41] h8300: " Al Viro
2020-06-29 18:26   ` [PATCH 33/41] hexagon: " Al Viro
2020-08-11 18:35     ` Brian Cain
2020-06-29 18:26   ` [PATCH 34/41] nios2: " Al Viro
2020-06-29 18:26   ` [PATCH 35/41] nds32: " Al Viro
2020-06-29 18:26   ` [PATCH 36/41] parisc: " Al Viro
2020-06-29 18:26   ` [PATCH 37/41] xtensa: " Al Viro
2020-06-29 18:26   ` [PATCH 38/41] csky: " Al Viro
2020-06-29 18:26   ` [PATCH 39/41] regset: kill ->get() Al Viro
2020-06-29 18:26   ` [PATCH 40/41] regset(): kill ->get_size() Al Viro
2020-06-29 18:26   ` [PATCH 41/41] regset: kill user_regset_copyout{,_zero}() Al Viro
2020-07-23  8:00 ` [RFC][PATCHSET] regset ->get() rework Christoph Hellwig
2020-07-23 17:27   ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200629203028.GB2786714@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=davem@davemloft.net \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).