suspend/resume test / getting rid of APM

[Mike (mwester)]

Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> | Andy Green wrote:
> |
> |> What it impacts is what we should test against.
> |
> | Exactly my point.
> |
> |> It's fine there are an
> |> uncontrolled number of rootfs out there with random things in, but it
> |> means I don't have time to test against them and rely on the users of
> |> the rootfs to inform about problems.
> |
> | And that's exactly what we have in this case -- a report from a user.
> |
> |> It looks like Jeremy is planning to be "internal tester" for kernel on
> |> whatever rootfs he prefers
> |
> | Great.  But let's not summarily dismiss the bug reports from others who
> | choose not to use whatever rootfs that turns out to be.
> 
> Really.  Well, I'll give your wisdom about that some deep thought.

Thanks.  You really should take a few minutes to touch base with the
other distros yourself, you know -- I'm certainly happy to keep pointing
out that there are users beyond Android and custom rootfs, but I do have
other things to work on.

> |> Does Android need APM or is this just FUD?
> |
> | Android was mentioned because it is a prominent example of an external
> | rootfs that the Om kernel team seems to take seriously.  I *do* know for
> 
> So, just FUD.

Nope, just trying to get your attention to the matter.  Which it has
done, and your comments below certainly help clarify your position.  Do
you speak for Openmoko, or is this just your personal opinion showing
right now?

> | a fact that the FSO distro and the SHR distros both use apmd, and the
> | rootfs' with the pre-canned Qtopia and the Qt Extended rootfs' both use
> | apmd.  I'm not sure what the Debian rootfs uses, but I believe it to be
> | apmd as well.
> 
> Hey you know that guy who writes the weekly Openmoko reports, even he
> said 20th Oct:  ''I would like to make an unrequested announcement for
> the sake of the good vertical communication:  Kernels currently has the
> APM power management interface is still compiled in. This has been
> deprecated for years and is doomed to go away. Hopefully apm -s will
> still work for suspend, but userspace applications that still use the
> deprecated apm interface SHOULD take action, preferably sooner than
> later.''
> 
> http://lwn.net/Articles/303942/

Thanks for the sermon.  It is Sunday, after all, and a little preaching
to the choir is traditional, no?

Who the heck is "that guy", and is he (or are you) generating the
patches to replace apm in all the user-space stuff out there?

I didn't think so.

Which is why I'm pointing out that now is not the right time.  But do go
on, what more do you have to say that could further hinder Openmoko's
interests in advancing the newer kernel?

> You know thinking about this 2.6.28 step up is probably the right time
> to disable APM in the kernel completely if that's really a good idea.
> There's already a bunch of attention needed for the move, and people in
> all rootfs will be aware that this update is coming.  At the moment we
> have APM emulation and CONFIG_APM_POWER in there, tomorrow I'll give it
> a go with these disabled and see what blows up.

Ah!  I see.  Yes, that certainly will help hinder the adoption of the
kernel, Good Plan!!  Anything else you'd like to torch while you're at it?


Thanks for your commentary, you've set things completely straight here.
 I've resisted forks for a long time, but there is no longer any point
in continuing to work fighting an uphill battle.  Good luck with your
plans to shove the current state of 2.6.28 down the users' throats.



Mike (mwester)