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]
Date:	Wed, 26 May 2010 13:23:00 -0500
From:	James Bottomley <James.Bottomley@...e.de>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Peter Zijlstra <peterz@...radead.org>, Pavel Machek <pavel@....cz>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Arve Hj?nnev?g <arve@...roid.com>,
	Florian Mickler <florian@...kler.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Stern <stern@...land.harvard.edu>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Len Brown <len.brown@...el.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Tejun Heo <tj@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Nigel Cunningham <nigel@...onice.net>,
	Ming Lei <tom.leiming@...il.com>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	linux-doc@...r.kernel.org, Matthew Garrett <mjg59@...f.ucam.org>,
	Greg KH <gregkh@...e.de>, tytso@....edu
Subject: Re: [PATCH 1/8] PM: Opportunistic suspend support.

On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:
> On Wed, 26 May 2010, James Bottomley wrote:
> > On Wed, 2010-05-26 at 19:01 +0200, Peter Zijlstra wrote:
> > > On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote:
> > > > On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote:
> > > > > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote:
> > > > > > > Or make the suspend manager a C proglet and provide a JNI interface,
> > > > > > > or whatever.
> > > > > > 
> > > > > > It's a fairly large piece of code to try to rewrite in C, so I don't
> > > > > > think that's feasible on a reasonable timescale.  Android does have the
> > > > > > concept of special sockets that can be used to communicate from less to
> > > > > > more privileged processes (it has a very segmented runtime model), so
> > > > > > these might be usable ... they have a drawback that they're essentially
> > > > > > named pipes, so no multiplexing, but one per suspend influencing C
> > > > > > process shouldn't be a huge burden. 
> > > > > 
> > > > > It wouldn't need to convert the whole Frameworks layer into C, just
> > > > > enough to manage the suspend state.
> > > > > 
> > > > > Anyway, I think there's been enough arguments against even the concept
> > > > > of opportunistic/auto-suspend, and I for one will object with a NAK if
> > > > > Rafael send this to Linus.
> > > > 
> > > > It was submitted already. I tried to followup with NAK, but can't
> > > > currently see it in the archive.
> > 
> > You mean this one:
> > 
> > https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html
> > 
> > ?
> > 
> > > It was apparently hidden on some funky list.
> > 
> > Sending a PM pull request to the PM list doesn't really strike me as the
> > height of obfuscation.  Plus almost everyone who objected was on the cc
> > list.
> > 
> > >  Hiding pull requests is bad enough, but hiding pull requests for
> > > contended features is just plain wrong.
> > 
> > I don't think it's a conspiracy ... just standard operating procedure
> > for this subsystem.  I do think cc'ing lkml is good practise (having
> > been yelled at for not doing that in the past) but it's certainly not
> > universal practise.
> 
> At least it would be good style for a topic which is
> 
>    1) contended like this one
> 
>    2) pushing an intrusive feature last minute which has been merged
>       into the pm tree barely two days ago.

Don't disagree ... I was just explaining how it could happen while not
being a conspiracy.

> Darn, _we_ have to deal with that forever as it sets a crappy user
> space ABI in stone.

I really don't see how it is ... the ABI comes with a switch that allows
it to be disabled, so only platforms wishing to use it have to support
it.  Even on those platforms that do support it, we can translate most
of it into pm QoS stuff and if one day someone solves the rogue app
problem, we can migrate over.

James


--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ