Date:	Fri, 28 May 2010 10:37:13 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	tytso@....edu
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.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)

> Keep in mind, though, that a solution which is acceptable for Android
> has to include making sure that crappy applications don't cause the

Ted if you are speaking for Android do you think you should post from a
google address or with a google .sig ?

> battery to get drained.  There seem to be some people who seem
> adamently against this requirement.  From the Android folks'
> perspective, this is part of what is required to have an open app
> store, as opposed to one where each application has to be carefully
> screened and approved ala the Apple iPhone App Store.

The other vendors appear to be managing nicely without magic blockers. I
conjecture therefore there are other solutions.

> We need to agree on the requirements up front, because otherwise this
> is going to be a waste of everyone's time.

This is why I am trying to understand the problem properly.

> And if we can't get agreement on requirements, I'd suggest appealing
> this whole thing to Linus.  Either he'll agree to the requirements
> and/or the existing implementation, in which case we can move on with

The existing implementation has been comprehensively rejected by half the
x86 maintainers and scheduler people to start with. That's a fairly big
'No'.

> our lives, or he'll say no, in which case it will be blately obvious
> that it was Linux developer community who rejected the Android
> approach, despite a fairly large amount of effort trying to get
> something that satisfies *all* of the various LKML developers who have

Ted save the politicing and blame mongering for management meetings
please.

If we don't have a solution it means that between us we couldn't find a
viable solution. Maybe there isn't one, maybe we missed it. It's as much
'google rejects kernel approach' as 'kernel rejects google approach' and
more importantly its actually 'we (cumulative) were not smart enough
between us to figure it out'

> P.S.  Keep in mind how this looks from an outsider's perspective; an
> embedded manufacturer spends a fairly large amount of time answering
> one set of review comments, and a few weeks later, more people pop up,
> and make a much deeper set of complaints, and request that the current
> implementation be completely thrown out and that someone new be
> designed from scratch --- and the new design isn't even going to meet
> all of the requirements that the embedded manufacturer thought were
> necessary.  Is it any wonder a number of embedded developers have
> decided it's Just Too Hard to Work With the LKML?

In some cases it is easier to do stuff yourself than work with others.
One of the conditions of working in a public space is that you do so
without harming others. This is why in much of the western world you can
drive a car around your own land without a licence but must have one to
drive on a public road. This is why a restuarant must meet different food
standards to a home kitchen. This is why the kernel standards are higher
than what you go off and do in private.

Android is a very unique and extremely narrow environment. If it really
is special enough to need its own kernel fork it isn't the first case for
that and it's not a problem. The GPL is quite happy to encourage this.
Time will then answer the questions because in 3 years time either every
non Google phone will be kicking butt without suspend blockers, or every
phone vendor using Linux with a traditional user space will be demanding
them.

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/

Powered by blists - more mailing lists