[PATCH 06/14] sysctl: Add size to register_sysctl
Joel Granados
j.granados at samsung.com
Fri Jul 28 00:41:46 PDT 2023
On Thu, Jul 27, 2023 at 08:42:02AM -0700, Luis Chamberlain wrote:
> On Thu, Jul 27, 2023 at 02:22:00PM +0200, Joel Granados wrote:
> > On Wed, Jul 26, 2023 at 10:58:30AM -0700, Luis Chamberlain wrote:
> > > On Wed, Jul 26, 2023 at 04:06:26PM +0200, Joel Granados wrote:
> > > > In order to remove the end element from the ctl_table struct arrays, we
> > > > replace the register_syctl function with a macro that will add the
> > > > ARRAY_SIZE to the new register_sysctl_sz function. In this way the
> > > > callers that are already using an array of ctl_table structs do not have
> > > > to change. We *do* change the callers that pass the ctl_table array as a
> > > > pointer.
> > >
> > > Thanks for doing this and this series!
> > >
> > > > Signed-off-by: Joel Granados <j.granados at samsung.com>
> > > > ---
> > > > diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
> > > > index 0495c858989f..b1168ae281c9 100644
> > > > --- a/include/linux/sysctl.h
> > > > +++ b/include/linux/sysctl.h
> > > > @@ -215,6 +215,9 @@ struct ctl_path {
> > > > const char *procname;
> > > > };
> > > >
> > > > +#define register_sysctl(path, table) \
> > > > + register_sysctl_sz(path, table, ARRAY_SIZE(table))
> > > > +
> > > > #ifdef CONFIG_SYSCTL
> > >
> > > Wasn't it Greg who had suggested this? Maybe add Suggested-by with him
> > > on it.
> > Yes. I mentioned him in the cover letter and did not add the tag because
> > I had not asked for permission to use it. I'll drop him a mail and
> > include the suggested-by if he agrees.
>
> FWIW, I never ask, if they ask for it, clearly they suggested it.
I was following Documentation/process/submitting-patches.rst:
"... Please note that this tag should not be added without the
reporter's permission... ".
In any case, Greg has already said yes :)
>
> > > Also, your cover letter and first few patches are not CC'd to the netdev
> > > list or others. What you want to do is collect all the email addresses
> > > for this small patch series and add them to who you email for your
> > > entire series, otherwise at times they won't be able to properly review
> > > or understand the exact context of the changes. You want folks to do less
> > > work to review, not more.
> > Here I wanted to avoid very big e-mail headers as I have received
> > rejections from lists in the past. But I for this set, the number of
> > e-mails is ok to just include everyone.
>
> I hear that from time to time, if you have issues with adding folks on
> the To address it may be an SMTP server issue, ie, corp email SMTP
> server issues. To fix that I avoid corp email SMTP servers.
My experience was more from the lists rejecting the e-mail because the
header was too big. With that said, I'll look into SMTP alternatives to
reduce possible errors
>
> Luis
--
Joel Granados
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230728/bb36f5bd/attachment-0001.sig>
More information about the linux-arm-kernel
mailing list