On Thu, 27 May 2010, Florian Mickler wrote: > On Wed, 26 May 2010 22:03:37 +0200 > Vitaly Wool <vitalywool@xxxxxxxxx> wrote: > > > On Wed, May 26, 2010 at 9:56 PM, Florian Mickler <florian@xxxxxxxxxxx> 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. > 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. Thanks, tglx _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
