Re: [PATCH v2 00/18] sysctl: constify sysctl ctl_tables

From: Thomas Weißschuh
Date: Fri Dec 15 2023 - 11:41:19 EST


On 2023-12-12 23:51:30-0800, Luis Chamberlain wrote:
> On Tue, Dec 12, 2023 at 10:09:30AM +0100, Joel Granados wrote:
> > My idea was to do something similar to your originl RFC, where you have
> > an temporary proc_handler something like proc_hdlr_const (we would need
> > to work on the name) and move each subsystem to the new handler while
> > the others stay with the non-const one. At the end, the old proc_handler
> > function name would disapear and would be completely replaced by the new
> > proc_hdlr_const.
> >
> > This is of course extra work and might not be worth it if you don't get
> > negative feedback related to tree-wide changes. Therefore I stick to my
> > previous suggestion. Send the big tree-wide patches and only explore
> > this option if someone screams.
>
> I think we can do better, can't we just increase confidence in that we
> don't *need* muttable ctl_cables with something like smatch or
> coccinelle so that we can just make them const?

The fact that the code compiles should be enough, no?
Any funky casting that would trick the compiler to accept it would
probably also confuse any other tool.

> Seems like a noble endeavor for us to generalize.
>
> Then we just breeze through by first fixing those that *are* using
> mutable tables by having it just de-register and then re-register
> new tables if they need to be changed, and then a new series is sent
> once we fix all those muttable tables.

Ack. But I think the actual constification should really only be started
after the first series for the infrastructure is in.

Thomas