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: <20100528092552.087bd38a@schatten.dmk.lab>
Date:	Fri, 28 May 2010 09:25:52 +0200
From:	Florian Mickler <florian@...kler.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Vitaly Wool <vitalywool@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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)

On Thu, 27 May 2010 15:35:18 +0200 (CEST)
Thomas Gleixner <tglx@...utronix.de> wrote:

> On Thu, 27 May 2010, Florian Mickler wrote:
> 
> > On Wed, 26 May 2010 22:03:37 +0200
> > Vitaly Wool <vitalywool@...il.com> wrote:
> > 
> > > On Wed, May 26, 2010 at 9:56 PM, Florian Mickler <florian@...kler.org> wrote:
> > > 
> > > > Your approach definitely sounds better than the current solution.
> > > > What about mapping suspend blocker functionality later on, when this
> > > > interface exists, on to this new approach and deprecating it?
> > > 
> > > What about coming back after some while with the appropriate solution
> > > when it's ready instead of stubbornly pushing crap?
> > > 
> > > ~Vitaly
> > 
> > Because quite frankly, for a good part of linux users, suspend blockers
> > is already in the kernel. It's just an historical mistake that they are
> > not in the linux kernel's hosted on kernel.org. 
> 
> No, it's not a historical mistake. It's a technical decision _NOT_ to
> merge crap. If we would accept every crappy patch which gets shipped
> in large quantities as a defacto part of the kernel we would have a
> completely unmaintainable mess since years.
> > So why don't we do what we always do? Improve existing interfaces step
> > by step? 
> 
> Exactly, that's what we are going to do. We improve and extend
> existing interfaces step by step, but not by creating a horrible and
> unmaintainable mess in the frist place which we can never get rid of
> anymore.

Ok to your two paragraphs. I can understand this. 

Nonetheless, i'm convinced that there has to be some solution in
mainline to allow for what android does. But perhaps it needs more
refactoring and piggybagging on some more general constraint interface.

> 
> > Top Down approaches fail from time to time. Also it is not clear, that
> > that proposed interface works for the use cases. This has to be proven
> > by providing an implementation. 
> 
> Nobody prevents you to sit down and start with a prove of concept
> implementation.

Hmm... *scratch*... *lookaround* .. who?

Really, I'd first like to get the whole picture before doing anything.

> 
> Thanks,
> 
> 	tglx
--
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/