[systemd-devel] RFC: enable suspend to idle
Lennart Poettering
mzerqung at 0pointer.de
Thu Mar 8 22:22:25 UTC 2018
On Mo, 05.03.18 16:19, Oliver Neukum (oneukum at suse.com) wrote:
> On Fri, 2018-03-02 at 10:18 +0100, Lennart Poettering wrote:
>
> > But why wouldn't that be a kernel option? I mean, so far the goal was
> > to encode "reasonable defaults" in the kernel itself, so that
> > userspace is only used when those "reasonable defaults" do not apply
> > onto one local case.
> >
> > Really, already for compatibility reasons the kernel should just carry
> > the "reasonable defaults", so that it's not necessary to match it up
> > with a udev version that carries the right policy for it.
>
> Well, no. The kernel must carry conservative defaults that do no harm
> in any case. Setting defaults sensible for the class of systems systemd
> runs on is the job of udev.
>
> For now we are running with defaults taken from firmware, which can be
> expected to be tailored to the system it comes with.
> Falling back to conservative defaults would mean a regression in
> functionality.
I don't get it. If there's a "regression" in the kernel's behaviour,
then perhaps the kernel should be fixed there.
But again: we so far have not shipped rules with udev whose exclusive
job is to push default policy into the kernel that the kernel might as
well just apply on its own. And I don't think we should start with
that now.
Yes, udev is the right place for applying *local* policy,
i.e. specific deviations from the default that apply to specific
systems a user/admin maintains.
Yes, udev is also the right place for applying *generic* policy that
the kernel couldn't come up with all alone, i.e. that requires access
to other userspace components (let's say, the user database or such).
But no, udev is *not* the right place for default policy that might as
well be in the kernel anyway.
Sorry,
Lennart
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list