On Fri, May 03, 2024 at 04:09:40PM +0200, Thomas Weißschuh wrote: > Hey Joel, > ... > > # Motivation > > As I read it, the motivation for these constification efforts are: > > 1. It provides increased safety: Having things in .rodata section reduces the > > attack surface. This is especially relevant for structures that have function > > pointers (like ctl_table); having these in .rodata means that these pointers > > always point to the "intended" function and cannot be changed. > > 2. Compiler optimizations: This was just a comment in the patchsets that I have > > mentioned ([3,4,5]). Do you know what optimizations specifically? Does it > > have to do with enhancing locality for the data in .rodata? Do you have other > > specific optimizations in mind? > > I don't know about anything that would make it faster. > It's more about safety and transmission of intent to API users, > especially callback implementers. Noted. ... > > # Show the move > > I created [8] because there is no easy way to validate which objects made it > > into .rodata. I ran [8] for your Dec 2nd patcheset [7] and there are less in > > .rodata than I expected (the results are in [9]) Why is that? Is it something > > that has not been posted to the lists yet? > > Constifying the APIs only *allows* the actual table to be constified > themselves. > Then each table definition will have to be touched and "const" added. That is what I thought. thx for clarifying. > > See patches 17 and 18 in [7] for two examples. > > Some tables in net/ are already "const" as the static definitions are > never registered themselves but only their copies are. > ... best -- Joel Granados
Attachment:
signature.asc
Description: PGP signature
