[Bug 1184804] move kernel out of /boot
https://bugzilla.suse.com/show_bug.cgi?id=1184804 https://bugzilla.suse.com/show_bug.cgi?id=1184804#c103 --- Comment #103 from Ludwig Nussel <lnussel@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com