Comment # 103 on bug 1184804 from Ludwig Nussel

(In reply to Michal Suchanek from comment #102)
> (In reply to Ludwig Nussel from comment #97)
> > run time parsed file would needed to achieve different defaults for
> > different flavors. Looking at "kernel.hung_task_timeout_secs = 0" that our
> > kernels ship as sysctl file for example. That one actually is a kconfig
> > option "CONFIG_DEFAULT_HUNG_TASK_TIMEOUT".  Is there a benefit from setting
> 
> And many others aren't.
> 
> > that via sysctl rather than just setting the kconfig option to our default?

Didn't answer my question though :-) I'm asking for the advantages of the
sysctl method because of kconfig is actually equivalent or even better (because
it avoids an external mechanism) then maybe it's worth introducing kconfig
settings [upstream] for the other options too.

> > Product branding on the other hand is not kernel specific. It would place
> > drop-ins into /usr/lib/sysctl.d/. No kernel version or flavor involved. In
> > fact the current mechanism specifically loads exactly one file that is
> > /boot/sysctl.conf-%v and that one is owned by each individual kernel
> > package. So there is no way to add any kernel version or flavor specific
> > sysctl setting via extra package.
> 
> The file provided by kernel is tracked in git per kernel version and flavor.
> 
> You could surely write a service that applies sysctl settings per kernel
> flavor but nobody cared to write one.
> 
> Sure, if the file was in some specific location for decades and then you say
> "shoo, nothing should be here anymore" then that requires some adjustment to
> the consumers of that file. However, the reason for those changes is the
> filesystem restructuring, not this sysctl file.

You lost me here. From my PoV in the process of moving files around we
discovered some old concept (per kernel sysctl file) and settings that are
potentially outdated. I guess I shall file a separate bug for evaluating the
settings to see what's actually left.