linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100526230943.6f5e5b37@lxorguk.ukuu.org.uk>
Date:	Wed, 26 May 2010 23:09:43 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Florian Mickler <florian@...kler.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Vitaly Wool <vitalywool@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

> > suspend blockers are completely backwards as they basically disable
> > the kernels ability to do resource management.
> 
> I don't think this is a defect in the approach but the point of it. 

I think it's both. It's the point of it, and that itself is a defect. Its
designed wrongly.

> drivers code is needed anyway. What looses the kernel by implementing
> suspend blockers, and later a more finegrained approach and mapping the
> userspace part of suspend blockers on that finegrained approach later
> on?

The Linux approach is to do the job right. That means getting the
interface right and so it works across all the interested parties (or as
close as we can get).

> >   - how much delay of wakeups is tolerated (missing interface)
> 
> Doesn't solve the segregation problem and is probably overkill for most
> applications. I see this as an orthogonal thing (i.e. not
> affecting this merge). 

The key question that matters for suspend management is 'what wakeup
delay is tolerated'. So it's absolutely fundamental.

> True. But I wouldnt say, that it is the linux kernel who should force
> this politics onto its users.

This is the Linux way of doing things. It's like the GPL and being
shouted at by Linus. They are things you accept when you choose to take
part. Google chose to use Linux, if they want a feature upstream then the
way you get it there is to figure out how to solve the real problem and
make *everyone* (within reason) happy.

We now have suggestions how to do the job properly so the right thing is
probably to go and explore those suggestions not merge crap.

Merging crap won't help anyway. The rest of the kernel community can
still simply stonewall those interfaces, and a volunteer community has
ways of dealing with abuse of process, notably by simply not getting
around to, or implementing things directly contrary to the crap bits.

So it's not even in the interest of people to play political games. Even
if you get away with in the short term the people who rely on the junk
will end up out on a limb and holding the baby when the crap hits the fan
(see reiserfs)

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/