Re: [PATCH 3/8] arch/x86: Remove sentinel elem from ctl_table arrays

Joel Granados <[email protected]>
Newsgroups gmane.linux.ports.riscv,gmane.linux.file-systems,gmane.linux.kernel,gmane.linux.ports.arm.kernel,gmane.linux.ports.ppc64.devel,gmane.linux.ports.ia64
Message-ID <20230907082446.a4o46vka2vtes3h4@localhost>
On Wed, Sep 06, 2023 at 11:58:47PM +0200, Ingo Molnar wrote:
> 
> * Dave Hansen <[email protected]> wrote:
> 
> > On 9/6/23 03:03, Joel Granados via B4 Relay wrote:
> > > This commit comes at the tail end of a greater effort to remove the
> > > empty elements at the end of the ctl_table arrays (sentinels) which
> > > will reduce the overall build time size of the kernel and run time
> > > memory bloat by ~64 bytes per sentinel (further information Link :
> > > https://lore.kernel.org/all/ZO5Yx5JFogGi%[email protected]/)
> > > 
> > > Remove sentinel element from sld_sysctl and itmt_kern_table.
> > 
> > There's a *LOT* of content to read for a reviewer to figure out what's
> > going on here between all the links.  I would have appreciated one more
> > sentence here, maybe:
> > 
> > 	This is now safe because the sysctl registration code
> > 	(register_sysctl()) implicitly uses ARRAY_SIZE() in addition
> > 	to checking for a sentinel.
> > 
> > That needs to be more prominent _somewhere_.  Maybe here, or maybe in
> > the cover letter, but _somewhere_.
> > 
> > That said, feel free to add this to the two x86 patches:
> > 
> > Acked-by: Dave Hansen <[email protected]> # for x86
> 
> Absolutely needs to be in the title as well, something like:
> 
>    arch/x86: Remove now superfluous sentinel elem from ctl_table arrays
Done. Will wait to see if other ppl have more comments to send out V2

Thx.
> 
> With that propagated into the whole series:
> 
>    Reviewed-by: Ingo Molnar <[email protected]>
> 
> Thanks,
> 
> 	Ingo

-- 

Joel Granados

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
signature.asc (application/pgp-signature, 659 B)
-----BEGIN PGP SIGNATURE-----

iQGzBAABCgAdFiEErkcJVyXmMSXOyyeQupfNUreWQU8FAmT5iM0ACgkQupfNUreW
QU8bUwv/fHvrxw5jNdVywGXfBd7e+5oIULa8H+WaPDRFBqcXRCiP5e+Lm2mdytxR
6Qy5bFl4klUIDRa6aQR6Rz02E0hmsNe+VsgDTRi0PWWF3407VH4E1wjmOj5aT2VG
PLGzd4HXCHLQbzQeC11Io/4nlEYU75Dd4gnkaRucqUKcXPrOlkb9hy0xySwAw7D8
5uzagt62DQOKNRhztEgNmWIIqaDojwCT6XT9JLtXXuCMuiTQF7S2nTKPKGzUqWVg
S8uigDN5928T19ra+u4tLjCEP8/Cdmqp5jSZdV2RDpPp/iANEtWK+S4iSMq+P86D
kZDrtJfMxSPx9I+TPaNrf0/FJwrU9fvVvuyx/SnF4Hl2K+10RRgMiBQxV9zMStAt
vyVqngOs646y+02tKZ/Z3xfJeZ5W/DiHoOk1kBI0/EYBXuHbM5W2OUfz4rNWHw/a
b43A8zoLfRKBzp9mKJixlprQk0sHv9jm8Y7RIbM2R6OkLgUJTDvwGX08WPDBA/ao
HEVK/mlZ
=aiqw
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.