On Tue, Aug 06, 2024 at 08:57:37PM +0200, Solar Designer wrote: > On Tue, Jul 16, 2024 at 04:16:56PM +0200, Joel Granados wrote: > > sysctl changes for 6.11-rc1 > > > > Summary > > > > * Remove "->procname == NULL" check when iterating through sysctl table arrays > > > > Removing sentinels in ctl_table arrays reduces the build time size and > > runtime memory consumed by ~64 bytes per array. With all ctl_table > > sentinels gone, the additional check for ->procname == NULL that worked in > > tandem with the ARRAY_SIZE to calculate the size of the ctl_table arrays is > > no longer needed and has been removed. The sysctl register functions now > > returns an error if a sentinel is used. > > > > * Preparation patches for sysctl constification > > > > Constifying ctl_table structs prevents the modification of proc_handler > > function pointers as they would reside in .rodata. The ctl_table arguments > > in sysctl utility functions are const qualified in preparation for a future > > treewide proc_handler argument constification commit. > > As (I assume it was) expected, these changes broke out-of-tree modules. > For LKRG, I am repairing this by adding "#if LINUX_VERSION_CODE >= > KERNEL_VERSION(6,11,0)" checks around the corresponding module changes. > This works. However, I wonder if it would possibly be better for the > kernel to introduce a corresponding "feature test macro" (or two, for > the two changes above). I worry that these changes (or some of them) > could get backported to stable/longterm, which with the 6.11+ checks > would unnecessarily break out-of-tree modules again (and again and again > for each backport to a different kernel branch). Feature test macro(s) > would avoid such further breakage, as they would (be supposed to be) > included along with the backports. > > Joel, Linus, or anyone else - what do you think? And in general, would As mentioned by Thomas; These changed must not be backported and therefore there is not concern about backport consequences. > it be a good practice for Linux to be providing feature test macros to > indicate this sort of changes? Is there a naming convention for them? I don't think that would be a good practice. IMO, a good way to handle these things in out-of-tree modules is the LINUX_VERSION_CODE hack. You can see it here for the same reason : https://github.com/cryptodev-linux/cryptodev-linux/commit/99ae2a39ddc3f89c66d9f09783b591c0f2dbf2e9 ... Best -- Joel Granados
