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