https://bugzilla.suse.com/show_bug.cgi?id=1202206 https://bugzilla.suse.com/show_bug.cgi?id=1202206#c13 Michal Kube��ek <mkubecek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bpetkov@suse.com Flags| |needinfo?(bpetkov@suse.com) --- Comment #13 from Michal Kube��ek <mkubecek@suse.com> --- (In reply to Claudio Fontana from comment #12)
"- use value from master if the option exists there", but in master it was enabled, so something might have gone wrong in the process.
The commit message also says "for each option, use first rule which applies" and in this case it's "use value from SLE15-SP1 if the option exists there". In other words, the value was inherited from SLE15-SP1 (the previous SP). Digging deeper, SLE15 inherited the value from SLE12 and in SLE12, the config option was disabled by kernel-source commit 253e6b166dd4 ("Update config files."). I doubt Borislav does still remember, after 8 years, why he did disable it back then so I guess this serves mostly as a memento emphasizing the importance of useful commit messages. But let's ask him anyway in case he does actually remember. I suppose right now the key question is not really who disabled the config option and why but if enabling it in a released product would either break kABI or change user visible behaviour in a way that could be seen as a bug by some of our customers/users. The answer to the first part seems to be negative (I did not test it and only checked quickly for the most obvious problems), for the second part, I'm afraid I'm not the right person to answer that. I always lived under the impression that userspace is responsible for the synchronization between RTC and system time. Boris, do you happen to know what was the reason for disabling CONFIG_RTC_HCTOSYS config option in kernel-source commit 253e6b166dd4 ("Update config files.") in SLE12 branch? -- You are receiving this mail because: You are on the CC list for the bug.