On Mo, 01.10.18 15:59, Peter Robinson (pbrobinson(a)gmail.com) wrote:
> The thing though is: the hibernation subsystem in the Fedora
> 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.
> 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
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
Lennart Poettering, Red Hat