Message-ID: <20100809201822.441905f7@lxorguk.ukuu.org.uk>
Date:	Mon, 9 Aug 2010 20:18:22 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	paulmck@...ux.vnet.ibm.com
Cc:	"Ted Ts'o" <tytso@....edu>,
	Felipe Contreras <felipe.contreras@...il.com>, david@...g.hm,
	Brian Swetland <swetland@...gle.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	arve@...roid.com, mjg59@...f.ucam.org, pavel@....cz,
	florian@...kler.org, rjw@...k.pl, stern@...land.harvard.edu,
	peterz@...radead.org, tglx@...utronix.de, menage@...gle.com,
	david-b@...bell.net, James.Bottomley@...e.de, arjan@...radead.org,
	swmike@....pp.se, galibert@...ox.com, dipankar@...ibm.com
Subject: Re: Attempted summary of suspend-blockers LKML thread, take three

> But wouldn't an office suite run as a power-oblivious application on an
> Android device?  After all, office applications do not need to run when

I was waiting for soemone to leap down the pit I dug  Office suites have
some quite important background activities. Consider the case of a power
oblivious Open Office. You type a critical document, you suspend, your
phone battery dies a bit later, you lost your document. Office suites do
timed backing up as one simple obvious example. That could become a power
aware behaviour but the truely power oblivious office suite is a myth.

> the screen is turned off, so these the applications do not need to use
> suspend blockers.  That said, I could easily imagine that significant
> work would be required to make OpenOffice run on Android, not due to
> suspend blockers, but rather due to Android's unusual user space.

You are tightly linking suspend blockers with Android. If they were a
sensible general solution they would be generic not tied closely to
Android

Some of the other bad assumptions being made in this discussion:

- That the phone is special. Todays Android phones are up with the PC's
  of some years back (but with better graphics and more faster storage),
  in a few more generations of the technology what will they look like ?
  I'm sure that within a few years there will be people playing Warcraft
  or similar on their phone in the train.

- That Android will continue to tbe offering the same services in future
  as today. If it does it'll go the way of PalmOS and Symbian. Equally
  you can't just bust all the apps as it changes

As devices get more complex and varied you cannot afford to put the
detailed awareness of platform behaviour in the applications. It
doesn't scale. Android developers are haivng enough fun coping with all
the OS variants, customisations and new phones - and thats far less
variety than PC hardware. Generally the PC app folks are not having the
same level of problem - so ask why ?

> On devices that do not have suspend blockers, a normal application runs
> in a manner similar to a hypothetical Android application that acquires
> a suspend blocker when it starts and holds that suspend blocker until
> it exits.  In contrast with Android, this situation requires that each
> and every application be carefully written to avoid battery drain,
> which I suspect is what Ted is getting at with his King Canute analogy.

Which is flawed and not the case. The same argument could be made for
multi-tasking

DOS	"Each application implements its own internal
	multitasking/polling if needed"

Windows 3.x	"Each application has an event loop and is built
in a certain way" (the 'suspend blocker' mentality)

Real OS		"The scheduler operates in a manner which prevents
CPU hogs breaking the system or abusing it sufficiently to threaten its
functionality"

The same applies to power. Only the OS has the big picture and can hide
the hardware and general policy variety from the application.

OpenOffice runs on netbooks, laptops, servers, even big non x86 boxes. It
runs on virtual machines, it runs in power sensitive environments, it
runs in thermally constrained environments, it runs in I/O constrained
environments, it runs in latency constrained environments etc etc

All the same code, true some work has been done to make it behave
politely but the rest is down to the OS doing its job - deploying the
resources available while considering and obeying the constraints
present, in a manner which makes best use of the resources to achieve the
policy goals of the system.

And not unsurprisingly that all starts to look like Stafford Beer's good
old viable systems model.

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