Linus,

As mentioned on my first pull request for sysctl-next, for v6.4-rc1
we're very close to being able to deprecating register_sysctl_paths().
I was going to assess the situation after the first week of the merge
window.

That time is now and things are looking good. We only have one stragglers
on the patch which had already an ACK for so I'm picking this up here now and
the last patch is the one that uses an axe. Some careful eyeballing would
be appreciated by others. If this doesn't get properly reviewed I can also
just hold off on this in my tree for the next merge window. Either way is
fine by me.

I have boot tested the last patch and 0-day build is ongoing. You can give
it a day for a warm fuzzy build test result.

Luis Chamberlain (2):
  kernel: pid_namespace: simplify sysctls with register_sysctl()
  sysctl: remove register_sysctl_paths()

 fs/proc/proc_sysctl.c     | 55 +++------------------------------------
 include/linux/sysctl.h    | 12 ---------
 kernel/pid_namespace.c    |  3 +--
 kernel/pid_sysctl.h       |  3 +--
 scripts/check-sysctl-docs | 16 ------------
 5 files changed, 6 insertions(+), 83 deletions(-)

-- 
2.39.2

On Tue, May 02, 2023 at 07:33:27PM -0700, Luis Chamberlain wrote:
> You can give it a day for a warm fuzzy build test result.

0-day gives its blessings.

  Luis

On Wed, May 3, 2023 at 9:24 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Tue, May 02, 2023 at 07:33:27PM -0700, Luis Chamberlain wrote:
> > You can give it a day for a warm fuzzy build test result.
>
> 0-day gives its blessings.

Well, it's not like I can pull anyway, since you didn't actually say
where to pull *from*. And I don't want to randomly apply patches when
I know you have a git tree for this.

So please do a proper pull request.

              Linus

On Wed, May 03, 2023 at 11:29:10AM -0700, Linus Torvalds wrote:
> On Wed, May 3, 2023 at 9:24 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >
> > On Tue, May 02, 2023 at 07:33:27PM -0700, Luis Chamberlain wrote:
> > > You can give it a day for a warm fuzzy build test result.
> >
> > 0-day gives its blessings.
> 
> Well, it's not like I can pull anyway, since you didn't actually say
> where to pull *from*. And I don't want to randomly apply patches when
> I know you have a git tree for this.
> 
> So please do a proper pull request.

Sorry thought you don't mind a few patches, so ditched the formalities
for the pull. Now I know you prefer to pull over a couple of patches,
will send up next!

  Luis

On Wed, May 3, 2023 at 12:10 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> Sorry thought you don't mind a few patches, so ditched the formalities
> for the pull.

So I don't mind patches per se, and when there's a reason for them I
have no problem at all taking them.

The reason is typically something like "let's short-circuit the normal
channels just to get this trivial thing sorted out and we can forget
about it", but it can also be just a practical thing like "I'm
traveling so it would be easier if you'd just pick up this patch
directly from the mailing list".

Or it could be "I don't have a git tree since I'm not a main
developer, so I just send patches".

All of those are situations where I'll happily take patches directly.

But on the whole, when there isn't any real reason to avoid a pull
request, I'd much rather have the full thing with signature and
everything...

               Linus