RFC: enable suspend to idle

[mzerqung@xxxxxxxxxxx (Lennart Poettering)]

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