On Mon, Oct 1, 2018 at 3:42 PM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > On Mo, 01.10.18 09:14, Justin Forbes (jmforbes@xxxxxxxxxxx) wrote: > > > > Lennart made a really interesting observation here, systemd > > > is just proxying if "cat /sys/power/disk" indicates that > > > hibernate is supported. > > > > > > > No, that is not what systemd is doing. The kernel provides a > > mechanism, it does absolutely nothing with that mechanism unless told > > to do so. What systemd is actually doing is creating a policy around > > that mechanism. > > Well, we do provide a way to disallow hibernation in systemd, that's > not the point. > > The thing though is: the hibernation subsystem in the Fedora kernel is > in a relatively unique situation: it's enabled and installed on all > installations by default, and adds a substantial, relatively invasive, > non-trivial subsystem to the kernel — all while (as I understand) the > Fedora kernel maintainers are not really willing to maintain it with > the greatest love, and show no interest in turning this into a > universally supported mechanism. Is there any other subsystem that is > equally invasive which is enabled on all systems but where the > maintainers are equally conservative in their will to support/fix it? > I don't think so... I also don't think your statement above is fair or correct. Firstly the kernel is large, and the combination of hardware is vast and the kernel team comprises ~3 people. So it's not that they don't maintain, fix, engage with upstream to deal with problems it's just that is limited with the resources available, especially when the bug reports can be as vast as "feature X stopped working" without details of the hardware or anything useful. I've seen numerous occasions when something has regressed and there's useful report various hibernate related issues be fixed, it's just hard with the limited resources, both people's time and actual HW to test on, to be able to be sure the functionality is good in all usecases. > To compare this with other cases: usually code that the package > maintainers don't want to maintain with the highest priority and > greatest love is split into separate RPMs, and not installed by > default. But in this case that's not really possible... Yes, that might be the case for some distros, for enterprise distros the functionality might even be provided via a different repository that you need to explicitly have to enable. Unfortunately for a hibernation it's not really a feature that can be split into a kernel sub package called kernel-hibernation-if-you-install-it-and-it-breaks-you-keep-both-pieces with the appropriate blinking lights. > Also, while of course I personally think that people should use > systemd's APIs to hibernate the system this is not really how the > world works. There are plenty of howtos on the internet that suggest > people to use the /sys interface directly to hibrenate the system from > their scripts. And hence that's how people often do it. Turning off > hibrenation in levels high up in the stack hence kinda is less than > ideal, as all those scripts don't care a tiny bit about that if they > use the API advertised by the kernel itself... > > > While this change would "solve" the problem, I do not believe it is > > the correct place to do so. As mentioned above, the mechanism is not > > flawed. Some hardware does not support the mechanism, and has no way > > of reporting as such, which is why policy has always been leave it off > > unless the user knowingly triggers it. Now we have changed the > > policy, in a way that seems pretty much universally undesirable, the > > solution is the revert the policy, not cripple the mechanism. > > I think it would be wise to generally only enable and advertise > features in the Fedora kernel that the kernel maintainers are actually > willing to support. To me it appears this is generally followed in all > cases, but in this case the kernel advertises that hibernation is > available, even though it is known to be broken in plenty cases with > noone actually caring about it. > > Also: I am sure there's a lot of disagreement of what the > responsibility of systemd is and what not, but I personally don't > think it's our job to decide whether a specific kernel subsystem is > high quality enough to override the kernel's own advertisement of it, > or even to judge whether the Fedora kernel team's willingness to > maintain said subsystem is big enough or not. I'd much rather if the > kernel team would decide on their own, and advertise on their own what > they think is good enough and supportable enough to be used by > everybody. > > Or to say this differently: own the thing or turn it off. > > Lennart > > -- > Lennart Poettering, Red Hat > _______________________________________________ > desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
