On Mon, Oct 1, 2018 at 10:14 AM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Mo, 01.10.18 15:59, Peter Robinson (pbrobinson@xxxxxxxxx) wrote: > >> > 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. > > Please don't misunderstand me on this. I am explicitly *not* > criticizing the kernel people for not wanting to give hibernation > their love. I don't expect them to, and as an upstream maintainer I > know exactly how important it is to make choices on what you want and > what you don't want to support. Hence: it's entirely fine by me if > hibernation is considered not supportable. I am just saying given that > things are the way they are I think it would be better to not > advertise it to userspace as working. Because currently to the layers > further up in the stack it looks like hibernation was perfectly well > supported even though it apparently is not. > If this were some new feature, I might agree with you, but hibernation has been in this state for literally a decade at this point. It seems odd to change policy around it after so long. It isn't just the code that has to change to support everything, it is system firmware which causes a lot of the issues, maintaining a massive blacklist is not worth the time or effort. Code issues in hibernation may not have the same priority kvm issues or graphics issues, but they aren't ignored either. Realistically we are dealing with legacy users here as new systems tend to support secure boot, which we enable by default, and disables hibernation already. Users falling outside of that category are either on legacy hardware, and why force them to change behavior, or advanced enough to turn off secure boot, and deal with said risks, in which case they could probably also make their own decisions on userspace hibernation policy and implement them if given a mechanism to do so. >> > 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. > > Yes, precisely, and the suggestion is to turn it off hence in the > kernel in a way that allows people who understand the uncertainty > around this subsystem to then enable it anyway if they like. > > i.e. make this subsystem opt-in instead of opt-out, in the package > that actually implements the subsystem (i.e. the kernel rpm), and > under control of the people who made the decision not to support it > with all their love (i.e. the kernel team). > > I don't think systemd should be in the business of second-guessing the > kernel team's choices on code quality and their desire to support > code. Because if the kernel doesn't turn this subsystem off, then we > have to… > Again, the kernel is simply providing a mechanism, we did not create a policy around this (except in the case of secure boot where the mechanism breaks a trust policy). The kernel at no point has said you *should* use this, only that it is available. There are a lot of things that the kernel makes available which may or may not be useful in your specific case, and we don't put policy around it. One of the advantages of a community distro such as Fedora, is that we *can* enable features that aren't guaranteed to work, but the community can use if it suits them. This is something that cannot be done as easily on enterprise distributions with service contracts and SLAs. We have a lot of modules and subsystems with few users, or where they are not reliable on *all* hardware. If we turned them all off, it might reduce our bug count a bit, but it would also do the community a disservice. I completely agree that hibernation should be opt-in instead of opt-out, but it should be done at the policy level, not the mechanism level. This is a policy decision. The policy level is not in the kernel. Justin _______________________________________________ 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
