User: Password:
Subscribe / Log in / New account

A suspend blockers post-mortem

A suspend blockers post-mortem

Posted Jun 3, 2010 2:04 UTC (Thu) by fuhchee (subscriber, #40059)
Parent article: A suspend blockers post-mortem

"in the end it appears to have come out with a better solution"

Would it be fair to say that it is premature to beat the drums of success
on this issue, before this better solution is implemented *and* merged?

(Log in to post comments)

A suspend blockers post-mortem

Posted Jun 3, 2010 3:50 UTC (Thu) by brendan_wright (subscriber, #7376) [Link]

> Would it be fair to say that it is premature to beat the drums of success on this issue, before this better solution is implemented *and* merged?

Exactly - Android has a solution that is working well right now in the real world. I hope this optimism about the new alternative proves to be justified!

A suspend blockers post-mortem

Posted Jun 3, 2010 18:57 UTC (Thu) by malor (guest, #2973) [Link]

I think corbet was maybe looking for something nice to say for both sides, but it was a bit of a stretch. In exchange for treating Google like shit and putting their developer(s) through hell, some early design work on an alternate approach has been done. Maybe, someday, it might be better, if someone actually wants to put the work in, but without a commercial drive to do so, I'm not seeing much motivation for it to happen.

If the kernel does actually get a better, implemented approach, then the kind words will have been right, but if it goes nowhere, then nothing particularly good would seem to have come from this particular mess.

I don't think pushing this out onto the embedded devs is right. This is purely a dev team organizational problem.

If people in the dev community have the power to demand a rewrite, they also need the power to authorize a merge. Either merge authority needs to move further down the dev tree, or external submitters need a method of avoiding the people who can only say no.

I hate to say it, but the kernel team is turning bureaucratic, an organization with layers of people who can only refuse new ideas, not approve them, but who don't reflect the actual opinions of the people with merge authority. This is classic bureaucracy, and it's killed an awful lot of great organizations over the years.

A suspend blockers post-mortem

Posted Jun 3, 2010 19:06 UTC (Thu) by corbet (editor, #1) [Link]

No, I wrote the article to say the things I thought needed to be said.

With regard to the solution: yes it's early to be celebrating. But I do know that there is a strong desire in the community to solve this problem; that's why a lot of non-Android people have put a lot of time into it. I also see that the shape of the proposed solution is such that it may solve a number of problems for other people as well. And it doesn't look hugely difficult to try out. So I think something will happen.

But, then, I've always been an optimistic person.

As for "merge authority," only one person really has that. But there has always been a strong consensus culture in the kernel community; it has traditionally been easy for a developer with any amount of standing in the community to hold things up. Nothing new there.

A suspend blockers post-mortem

Posted Jun 3, 2010 20:38 UTC (Thu) by farnz (subscriber, #17727) [Link]

It's interesting that you describe it as "treating Google like shit and putting their developer(s) through hell"; I see it very, very differently (and I've been following the threads on LKML as well as reading the articles here).

I see Google's developers coming up with a solution to a very specific problem, that's not going to help people outside of their devices, and that involves intrusive changes all over the kernel. By the time they bring it to the kernel folk, they're heavily invested in it - changing it is going to cost them a lot of effort.

Needless to say, they get a lot of pushback, as the solution they're proposing doesn't work for anything bar the areas Android is targetted at, yet requires all kernel developers to make allowances for them. At first, most of the pushback is met by the argument that they've shipped huge numbers of devices, and can't possibly change a design that they've made work.

Eventually, we get a statement of the problem that Google are trying to solve; as seems common with controversial kernel features, this triggers a whole pile of ideas, some of which get shot down as unworkable, others get refined into better solutions. We now seem to be at the stage where we're down to a single core idea for solving the problem, which is being refined into a decent userspace interface that can stay put forever, and a kernel interface that will work for now, but that can always be replaced.

In short, I see Google coming up with a short-sighted design, tied closely to details of their platform, and then (not maliciously, mind - it's hard to accept that you've made a mistake) trying to use their size to bully the kernel developers into accepting a bad solution to the problem, that's both intrusive and not helpful to non-Android users.

Had Google brought wakelocks/suspend blockers to the mainstream early in Android development (spinning it as something they do to save server power, for example, as Android couldn't come into the open at that point), they'd have had much less pain - they'd almost certainly have ended up implementing something closely related to the QoS constraints that seem to be winning the day now. Similarly, had they been able to get what they wanted in a tightly confined "android.ko", the kernel guys would probably have accepted it without this huge argument that's ensuing now. It's the combination of "this only solves our problem - the rest of you can go swivel, because we're shipping this", and "all of you need to allow for our solution to this problem, because it affects code all over the shop" that's caused the strife.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds