On Thu, Sep 04, 2025 at 07:03:56PM +0200, Vegard Nossum wrote: > > On 04/09/2025 04:51, Kees Cook wrote: > > On Mon, Sep 01, 2025 at 08:44:56PM +0200, Vegard Nossum wrote: > > > If you change sym_calc_visibility() to always return 'yes' for > > > transitional values then I don't think you need to touch > > > sym_calc_value() at all. > > > > Hm, it looks like sym_calc_visibility() doesn't strictly just look at > > visibility. And visibility seems to "last"? And I think the "tri" still > > can't just be "yes", don't we need the other stuff handled? > > > > Do you see a way to do it how you're suggesting? And now I wrote the > > regression tests so we can test any alternatives! ;) > > Here's what I had in mind (on top of your kcfi patchset), see the > attachment. > > It basically undoes all your additions to sym_calc_value() in favour of > two straightforward additions: > > @@ -214,6 +214,11 @@ static void sym_calc_visibility(struct symbol *sym) > struct property *prop; > tristate tri; > > + if (sym->flags & SYMBOL_HIDDEN) { > + sym->visible = yes; > + return; > + } > +
If this doesn't break "m" choices and the config doesn't show up in menuconfig, then yeah, I can do this. I'll give it a spin! -- Kees Cook