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;
Date:   Mon, 15 May 2023 13:24:06 -0700
From:   Luis Chamberlain <mcgrof@kernel.org>
To:     Joel Granados <j.granados@samsung.com>
Cc:     Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
        Iurii Zaikin <yzaikin@google.com>,
        Kees Cook <keescook@chromium.org>,
        linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/6] sysctl: Remove register_sysctl_table from parport
Message-ID: <ZGKU5vP8Anmfeen0@bombadil.infradead.org>
References: <CGME20230515071448eucas1p111c55b7078f1541f487c9dfb1a9f9c15@eucas1p1.samsung.com>
 <20230515071446.2277292-1-j.granados@samsung.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230515071446.2277292-1-j.granados@samsung.com>
Sender: Luis Chamberlain <mcgrof@infradead.org>
Precedence: bulk

On Mon, May 15, 2023 at 09:14:40AM +0200, Joel Granados wrote:
> This is part of the general push to deprecate register_sysctl_paths and
> register_sysctl_table. Parport driver uses the "CHILD" pointer
> in the ctl_table structure to create its directory structure. We move to
> the newer register_sysctl call and remove the pointer madness.

Nice! Thanks for doing this and unwinding the sysctl use case which
takes the cake for the obfuscation use case of sysctls.

> I have separated the parport into 5 patches to clarify the different
> changes needed for the 3 calls to register_sysctl_paths. I can squash
> them together if need be.

I think it makes sense to keep them that way.

> We no longer export the register_sysctl_table call as parport was the
> last user from outside proc_sysctl.c. Also modified documentation slightly
> so register_sysctl_table is no longer mentioned.

We can go further, but I'll explain in patch review on the patches.

> I'm waiting on the 0-day tests results.

Nice!

  Luis