| |||||||||||||
|
| |||||||||||||
See, NOW it makes sense...See, NOW it makes sense...Posted Feb 3, 2010 20:19 UTC (Wed) by Epicanis (guest, #62805)In reply to: Greg Kroah-Hartman: Android and the Linux kernel community by morrildl Parent article: Greg Kroah-Hartman: Android and the Linux kernel community "please do feel free to forward these inquiries to me, since you shouldn't have to deal with them." Maybe I'm reading too much into this (especially since I'm not a "kernel developer" by even the most ridiculous of standards) but what I'm getting from this is that you really DON'T want to work with mainline kernel developers. Perhaps Google isn't comfortable with the compromising and reduced control that would necessarily be involved in sharing responsibility with the mainline developers? While Greg KH presumably is interested in devices working on all Linux platforms, Google presumably feels "who cares about the rest, so long as it works on Google® phones running Android®". That, at least, is what this response implies to me. (That'd be understandable, but it might save a lot of pointless arguing if Google would just come out and say so explicitly if that's the case...)
(Log in to post comments)
See, NOW it makes sense... Posted Feb 3, 2010 20:28 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
note that such a policy would seem to contradict the google opensource policy that made the news a few weeks ago. That policy stated that every google opensouce project should be working to get their work upstream.
See, NOW it makes sense... Posted Feb 3, 2010 20:58 UTC (Wed) by morrildl (guest, #63330) [Link]
> Maybe I'm reading too much into this
You are.
> Perhaps Google isn't comfortable with the compromising and reduced
Wow, what is it with Linux people automatically jumping on the "control"
It's true that Android does a few unusual things in the kernel, and it's
For our part, meanwhile, we have working code that's running on millions of
And anyway, what's the hurry? Are we trapped in some hellish game where the
See, NOW it makes sense... Posted Feb 3, 2010 21:07 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Android runs on hardware where wakelocks are unnecessary. Retention mode is generally
equivalent to system suspend in terms of power, so all you need is for the kernel to stop scheduling tasks. There's no "new paradigm" here, there's simply an inelegant mass of code that ties your userspace to your kernel, buys you nothing in the process and prevents your code from going upstream.
Like I said, this could be rearchitected without breaking the existing userspace interface. It'd even
See, NOW it makes sense... Posted Feb 3, 2010 21:14 UTC (Wed) by dberlin (subscriber, #24694) [Link]
"Android runs on hardware where wakelocks are unnecessary. "
Great, sounds like you are volunteering to actually remove them and show that this is the case, right?
See, NOW it makes sense... Posted Feb 3, 2010 21:21 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
If I had (a) hardware, and (b) some indication that Android upstream would accept it, sure.
See, NOW it makes sense... Posted Feb 4, 2010 7:31 UTC (Thu) by cdibona (subscriber, #13739) [Link]
That's easily solved, Matt, just email me. :-)
See, NOW it makes sense... Posted Feb 4, 2010 11:36 UTC (Thu) by kragil (guest, #34373) [Link]
That answer just gave me an idea:
How about giving contributors not employed by Google or Open Handset members
It is easy to do (just grep some SCM output, or just put "providing proof"
Kernel hackers would certainly be ledgeable and if they bother to apply for
Disclaimer: I certainly wouldn't qualify.
See, NOW it makes sense... Posted Feb 4, 2010 14:12 UTC (Thu) by gregkh (subscriber, #8) [Link]
Google has been very generous in giving out free phones to lots of kernel developers in the past, so this isn't really an issue.
See, NOW it makes sense... Posted Feb 4, 2010 14:16 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Like I said, spending time on this would be conditional on some assurance that it wouldn't just be rejected out of hand. I'm reasonably sure that this can be implemented without any changes to applications being required, but it may need some (fairly minor) alterations to the underlying Android stack.
See, NOW it makes sense... Posted Feb 5, 2010 19:38 UTC (Fri) by jejb (subscriber, #6654) [Link]
> Like I said, spending time on this would be conditional on some assurance
> that it wouldn't just be rejected out of hand. I'm reasonably sure that > this can be implemented without any changes to applications being > required, but it may need some (fairly minor) alterations to the > underlying Android stack.
If google wishes to offer fair terms for this type of challenge, count me in. I've already done quite a bit of android hacking with the G1 Qualcomm gave me. It looks to me like the move off wakelocks (and possibly binders) can be contained to some small glue changes in bionic and some of the java classes.
I'd suggest reasonable terms be that if we get this working acceptably (meaning comparable battery life to the existing 2.6.29 implementation), Google would commit to moving to the upstream kernel we produce and integrating the necessary changes (whether ours or rewritten ones) into the android user code.
See, NOW it makes sense... Posted Feb 7, 2010 9:11 UTC (Sun) by swetland (subscriber, #63414) [Link]
I'd love some assurance that *our* patches wouldn't just be rejected out of hand too.
One thing we are working on doing is getting the external open tree to the point where it's trivial for somebody to check it out and do a full from-source build for Nexus One (which is completely unlockable and reflashable, as shipped from the factory). This then gives everyone some common ground to test patches against, and perhaps measure power consumption of various builds across the normal range of testcases.
At the moment the remaining issues are some build system cleanup, and sorting out redistribution of the handful of userspace proprietary binary modules (roughly 10 libraries/binaries -- fewer, if I'm reading the wiki right, than in a N900).
I can't promise you that we'd absolutely take a change -- it'd have to be verified to actually be better (or at least no worse), across the board, on power management, and that there were no regressions in stability or correctness of any driver. We spent quite a lot of time measuring power usage both in lab and field trial environments -- changes that fundamentally alter how this works get a lot of scrutiny.
See, NOW it makes sense... Posted Feb 7, 2010 19:07 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
So from my perspective, the three major sticking points are wakelocks, the early suspend/late resume code and the binder. We can argue over whether the binder code strictly needs to be in the kernel, but it's not something that has any real influence over the platform code. If we were in a world where the only significant difference between the mainline kernel and the Android one was binder support, I think that'd be the least of our problems.
The early suspend infrastructure is more interesting. I think it's fair to say that it's a somewhat hacky solution to the problem (take msm_fb - early_suspend and earlier_suspend?), but the problem it's solving is certainly legitimate. Rafael's been working on a mechanism for providing a power management dependency tree that's orthogonal to the device tree. I'd hope that this would provide the necessary functionality that we could do without early suspend, but it'd be great to talk about that.
Wakelocks are obviously the most controversial aspect of this. I think the main problem is that there's never been a terribly convincing answer as to why wakelocks are the appropriate solution to the problem. The upstream omap tree's approach has been to implement core suspend as a cpuidle state with appropriate latency restrictions. That fits in nicely with how other architectures manage this kind of functionality, so I think the onus is really on Google to explain why wakelocks provide more functionality than something that makes use of existing kernel code.
I appreciate that the "Please throw all of this out and rewrite it from scratch" attitude is a problem, and I'd entirely understand if Google don't feel that the work required to rework all of this in a way that upstream approves of would be justifiable. On the other hand, Android's absence from various forums (the collaboration summit, LPC, Linuxcon, the power management mini-summits and so on) makes it much harder for us to appreciate why this difference of opinion exists. It's true that the initial response to wakelocks was pretty universally negative without a lot of effort being spent on figuring out alternative solutions that would be mutually acceptable, and I'm certainly sorry that it happened that way - but at this point I suspect that we've been largely talking past each other for the best part of a year, and it would be good to spend some time figuring out why we have this fundamental disagreement before having another round of acrimonious debate culminating in another pile of code that goes nowhere.
See, NOW it makes sense... Posted Feb 8, 2010 5:56 UTC (Mon) by swetland (subscriber, #63414) [Link]
Yeah, I consider the binder a side-issue. In theory one could replace it entirely, if one were willing to write a bunch of userspace code that accomplished everything userspace needs from it, etc, etc, and it is self-contained and no other drivers depend on it.
I thought we had actually explained a number of situations where wakelocks provide value beyond existing solutions -- I'll have to dig through the linux-pm threads and try to extract some stuff from there. One thing we're looking to do is put together a clean writeup of the "why" behind all this as a basis for discussion.
I don't see how retention from idle (which we do as well) fully solves the problem -- since you can easily have situations, in an environment where you can't control every process/thread (300+ threads in a typical android system at boot -- yeah, kinda crazy, but it is what it is). Going to suspend means we don't need to worry about non-optimal software with polling/periodic behaviors causing the CPU to wake up more often than ideal. Also, you still have situations in which you *can't* go to full retention in idle because of a driver being busy (which is what idlelocks -- just another class of wakelock) are about.
I think it would be extremely valuable to get some folks together somewhere and try to hash some of this out. In general we are not opposed to slightly different ways of doing things as long as we accomplish what we need to accomplish power-wise. I mean, Arve's already respun the wakelock API (now suspend_blocker, no?) several times in response to various feedback.
I'd love to engage in a forum where the goal is to solve common problems rather than assign blame -- Greg's blogpost implying that he's giving a CELF keynote about how we suck does not create much enthusiasm on our side for attending, for example.
We know that some people would have been happier if we worked out a design for all of this before 1.0 shipped, but that didn't happen, and arguing about how practical it would have been or not doesn't really gain anybody anything. Figuring out how to collaborate on things so that future issues get sorted out earlier and more smoothly seems entirely worthwhile though.
So when/where is the next time/place that we could meet up with the other interest parties on the linux-pm front and talk about these things?
See, NOW it makes sense... Posted Feb 8, 2010 6:34 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
Right, it's absolutely true that the wakelock approach simplifies the userspace implementation,
but we could take a different view of things - at the most aggressive level, you could keep a userspace wakelock implementation and use the uswsusp interface to fire off the process freezer when all of them are released. All we'd need then would be a mechanism to provide a list of PIDs that you don't want frozen.
The drivers side of thing is more interesting, and I think that's something that could potentially
The next linux pm summit is planned for Boston in August, which is kind of far away. There's the
See, NOW it makes sense... Posted Feb 7, 2010 23:54 UTC (Sun) by kragil (guest, #34373) [Link]
I see another bug here .. why aren't all Googlers automatically LWN
subscribers? Do it like Canonical et al.
Chris? Fix that :)
Our editor is really cheap for big corps that have revenues like MS has
See, NOW it makes sense... Posted Feb 8, 2010 5:59 UTC (Mon) by cdibona (subscriber, #13739) [Link]
Any googler that wants an account can have one. We pay for it out of our
budget. Been like that for a number of years.
See, NOW it makes sense... Posted Feb 5, 2010 19:43 UTC (Fri) by jejb (subscriber, #6654) [Link]
OK, so to move this to a positive tone, We (that's me, mjg59 and any other developers who join) will accept a challenge to move android to the vanilla kernel:
http://lwn.net/Articles/373173/
Are our terms acceptable, or would you like to add other conditions?
See, NOW it makes sense... Posted Feb 3, 2010 21:23 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
well, assuming that phone hardware is similar, the Nokia phones would appear to be proof that you don't need wavelocks to get good battery life.
See, NOW it makes sense... Posted Feb 3, 2010 21:46 UTC (Wed) by jebba (✭ supporter ✭, #4439) [Link]
...but the userspace code to recharge the battery is completely closed...
See, NOW it makes sense... Posted Feb 3, 2010 21:48 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Which is entirely orthogonal to runtime power consumption.
See, NOW it makes sense... Posted Feb 3, 2010 21:49 UTC (Wed) by dcbw (guest, #50562) [Link]
The N900 uses TI OMAP processors and Nokia radios, which is different than Android phones which typically use integrated Qualcomm chipsets and radios.
But they both have to solve the same problems (power management) and the fact that Nokia seems to get good battery life out of their devices appears at first glance to be a counterpoint to the necessity of wakelocks.
See, NOW it makes sense... Posted Feb 3, 2010 21:55 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
I wasn't aware that android was supposed to be tied to a specific chipset. I was under the impression that it was intended to be used on a wide variety of devices.
is there anything that would prevent android from being run on the nokia phones, or the nokia software from running on android phones (other than the fact that some drivers are only in the android fork and the android fork does not include all the drivers in the main kernel)?
See, NOW it makes sense... Posted Feb 3, 2010 22:04 UTC (Wed) by dcbw (guest, #50562) [Link]
Android *isn't* tied to a specific chipset. But when Google was creating Android they built it for the reference design (HTC Dream which used a Qualcomm MSM7201A SoC). And Google doesn't appear to be interested in porting Android to other SoCs like TI's OMAP; they appear to be entirely focused on Qualcomm chipsets where they can leverage their existing investment.
As a company building phones, would you rather just use the same hardware Google build Android for, or would you rather invest a ton of time into porting Android to another SoC and write completely new SDIO, radio, power-management, etc drivers while your competitors come out with 3 new phones?
It makes a ton of sense that (AFAIK) nobody has come out with a non-Qualcomm Android phone, since to do so would require a significant investment. If you use Qualcomm MSM7K or MSM8K (snapdragon) platforms, then Google has already made that investment for you, for the most part.
See, NOW it makes sense... Posted Feb 3, 2010 22:10 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Not phones, but the Nook is android on a Samsung platform.
See, NOW it makes sense... Posted Feb 3, 2010 22:38 UTC (Wed) by dcbw (guest, #50562) [Link]
Interesting; though the scope there is quite a bit smaller; no real radio management, low-latency audio paths, fast 3D graphics, are required which makes the driver bring-up less intensive. Also the hardware refresh cycle for these is probably a lot slower than a phone, so you can recoup a lot more of your investment.
See, NOW it makes sense... Posted Feb 4, 2010 11:24 UTC (Thu) by broonie (subscriber, #7078) [Link]
Thing is, Linux has a pretty good mainline stack for all of these things (possibly excepting 3D) - to the extent that people play with mainline a lot of this stuff is available off the shelf.
See, NOW it makes sense... Posted Feb 4, 2010 11:35 UTC (Thu) by SimonKagstrom (subscriber, #49801) [Link]
The Samsung Spica Android phone is also built on their own platform (6410 I
believe).
See, NOW it makes sense... Posted Feb 3, 2010 22:13 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
so all the vendors working on android based e-readers, netbooks, etc should not be doing so, they should be using some other linux variant ans android only cares about phones with the current generation of qualcomm chipsets.
this also says that the next generation of qualcom chipsets may need a different OS as android is not working to be multi-platform.
See, NOW it makes sense... Posted Feb 3, 2010 22:49 UTC (Wed) by dcbw (guest, #50562) [Link]
I never said anything of the sort. Netbook and ebook reader makers can certainly use Android.
What I *did* say was that if you move away from the Qualcomm-based platform, you are going to be investing a *lot* more into the driver and architecture bring-up. But that could very well be a way of differentiating yourself in the market. It's a cost/benefit analysis and it appears that ebook reader makers have decided that over the long run they will make more money than it cost to port Android to a new architecture.
But the fact that almost all the phones running Android are doing so on Qualcomm 7k or 8k chipsets shows that most *phone* companies appear to be maximizing their investment by leveraging the work that Google has already done. Phone product cycles are also a lot faster than ebook reader product cycles, and phones have a lot more hardware in them (which requires more/different drivers) than ebook readers.
And just because Qualcomm comes out with a new platform doesn't mean your investment is worthless. Often new iterations of a chipset will contain only tweaks of the older hardware; they rarely rearchitect the entire system because that simply trashes all the money you've invested in the software so far. Which isn't smart.
For example, Android on the MSM8k can use mostly the same radio drivers (qmi), shared memory drivers (smd), network device (rmnet), etc that the MSM7k used. The GPU probably required a significantly modified driver, but at least you didn't have to rewrite *all* the drivers just to move from MSM7K -> MSM8K.
See, NOW it makes sense... Posted Feb 3, 2010 23:08 UTC (Wed) by cdibona (subscriber, #13739) [Link]
As an aside, the Verizon/Moto Driod runs on a TI OMAP. So...
See, NOW it makes sense... Posted Feb 3, 2010 23:59 UTC (Wed) by dcbw (guest, #50562) [Link]
Right you are. Quick question, I see a lot of @android.com on the OMAP patches. Who spearheaded the Android OMAP efforts here? Google, TI, Motorola, combination of all?
See, NOW it makes sense... Posted Feb 4, 2010 7:33 UTC (Thu) by cdibona (subscriber, #13739) [Link]
A combination. It's always a mix, from what I understand.
See, NOW it makes sense... Posted Feb 4, 2010 0:32 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
OMAP, of course, being a platform that achieves good battery life without wakelocks.
See, NOW it makes sense... Posted Feb 4, 2010 19:51 UTC (Thu) by rahvin (subscriber, #16953) [Link] As a company building phones, would you rather just use the same hardware Google build Android for, or would you rather invest a ton of time into porting Android to another SoC and write completely new SDIO, radio, power-management, etc drivers while your competitors come out with 3 new phones?I would rather see you upstream all your changes (including userspace), then TI or other phone makers can upstream and GPL all their changes (including userspace tools) and in the long run Android runs on anything that the Kernel runs on. There is a reason it's called a community. Rather that build everything yourself why not get upstream so that all the work others are doing can be used. That way if some new SOC maker comes to Google and says "we want you to use our chip" you simply tell them to get "X" into the Kernel and then you aren't dependent on one supplier/IP platform. I think you guys have fully missed the point of FOSS.
See, NOW it makes sense... Posted Feb 3, 2010 21:56 UTC (Wed) by dcbw (guest, #50562) [Link]
You're assuming wakelocks are the best solution to the problem. They may be the solution that Google came up with, but just because Google came up with it doesn't mean it's the best. And the kernel developers who reviewed the wakelock patches appear to disagree that it's the best solution.
So why didn't Google initiate discussion of advanced mobile power management techniques during the initial development of Android in 2007/2008, when everyone could come together and agree on a good design *before* you started shipping millions of products?
Of course if you have enough engineers you can forward-port until the cows come home, but that's not a great use of engineering talent...
On one side this is Linux developers appearing to whine that Google didn't do things the way they "should have been done", and on the other side it's Google appearing to be arrogant by expecting that every technical decision they made is the best one and that everyone else should see that and accept it as-is with great fanfare and many thanks.
See, NOW it makes sense... Posted Feb 3, 2010 23:19 UTC (Wed) by Epicanis (guest, #62805) [Link] Wow, what is it with Linux people automatically jumping on the "control" meme? This is purely a pragmatic thing.Control is "a pragmatic thing" - at least from the point of view of the control-holder. The point is, it's often seen as easier and more easily profitable to retain control over something than to let someone else have influence over one's business plans. The reason "Linux people" (I take it you are NOT a "Linux person"?) tend to be sensitive to this is because of how often it becomes a roadblock. Proprietary data formats, proprietary video and audio codecs, software patents, digital restrictions, proprietary hardware, trademark and copyright licensing... all there to retain control. Apple's profitability seems like a pretty good demonstration of how iron-fisted control can be pragmatic. I recognize that if it were the case that Google just doesn't want to deal with working out compromises with mainline kernel developers that this would probably be a purely pragmatic decision, perhaps on the assumption that not having to do so would decrease delays in Android development, and perhaps, like Apple, make it easier to control the perception of the Android brand (reducing the chance that a change somewhere in the kernel that Google doesn't operate on inadvertently causing performance problems for Android, for example). Obviously not everyone agrees that this is the best course of action in the long run, otherwise there wouldn't be all the arguing and occasional light snark that we're seeing over this. It doesn't help that Google occasionally does things that make people question its attitude towards Linux - Google often seems reluctant to port their standalone applications to Linux, for example. Admittedly this doesn't affect me as much, since the one Google application that I really like to use has maintained pretty good Linux support...so far. I just hope Marble develops fast enough to take over before Google decides to quietly drop development on the Linux versions of Google Earth... tl;dr - Google's motives likely are pragmatic rather than malicious, but from this discussion they really don't seem to like having to deal with mainline Linux development and a lot of people seem concerned about how this might cause problems for users of mainline Linux if Google decides to walk away.
See, NOW it makes sense... Posted Feb 3, 2010 23:59 UTC (Wed) by kragil (guest, #34373) [Link]
Insightful comment. 100% agree.
Might I add a quote from Aaron Seigos recent blog post about the N900:
"I've seen this played out many times while I've knocked around the
There is no successful, closed ecosystem monopoly in the devices world yet.
See, NOW it makes sense... Posted Feb 4, 2010 1:25 UTC (Thu) by Doogie (guest, #59626) [Link]
I think you hit the nail on the head about the control issue. Two of the most critical components of Android (linux kernel, dalvik vm) are now effectively incompatible forks of the (currently) more common implementations of the original technologies. Once there are a couple of hundred million Android devices out there, who's to say that the Google controlled branch of the Linux kernel isn't the "standard" one and Torvalds' isn't the incompatible fork? Just sayin' :)
Please excuse one more followup... Posted Feb 4, 2010 1:12 UTC (Thu) by Epicanis (guest, #62805) [Link] It's probably really strange that I feel compelled to post here - especially more than once. I'm not a developer nor do I even know any developers personally, I'm not wealthy enough to own Google stock, I don't own an Android-based device (although I would be happy to get one, I must confess I'd rather have something maemo-based...), and whether or not "wakelocks" ever get implemented in the Linux kernel almost certainly has zero direct effect on me. I think the only link I have to anyone with a direct stake in all this is that Greg KH maintains the staging tree where the only currently-working driver for my netbook's wireless network chipset resides. Why the heck do I care so much?... "For our part, meanwhile, we have working code that's running on millions of devices, and we (also quite reasonably) are not eager to do extensive modifications to it simply for the goal of upstreaming it."There. That (I think) is the entire point around which the argument turns. The rest of the PR fluff, hyperbole, and accusations flying in both directions seem to be obscuring this. (the following paragraph is based on my potentially-faulty understading of the Android development timeline - corrections welcome.) I understand Google doing the early development of Android in relative secrecy - it was probably the only way to get it working and have it out in the market before a surprised Apple/Microsoft/Etc. could stall it with patent lawsuits and whatnot. The customizations apparently surprised the mainline Linux developers too, though. "Here it is, mainline developers. Take it or leave it, but it's too late to change anything now that it's out." "What? What's all this? It looks like it has some problems." "You're leaving it then? Fine." I understand the business reasons that I assume Google had for doing things this way. It's the way that it's being presented that seems to be stoking the fires. And anyway, what's the hurry? Are we trapped in some hellish game where the goblins will devour us if we don't meet our quota for adding upstream code?There's the presentation thing again. If "us" and "our" are read to mean "Google", it reads an awful lot like "And anyway, what are you Linux people gonna do to us it if we don't get our code upstream? Nothing, that's what!" I'm guessing you just meant to convey that some code living independent of the mainline Linux kernel with no intention of ever being in the mainline kernel isn't the proverbial end of the world. I agree, actually - but it's still not unimportant. Since we have working code, and it's not "less open-source" just because it lives in a different repo, why is this even an issue?Here's my hypothesis, developed with all of the insightfulness and wisdom of a Random Pseudonymous Commenter: Google is a huge, wealthy, influential corporation who is known to use a lot of Linux and therefore presumably has some sense of its worth, but now has split off its own "Android Linux" kernel, with some incompatibilities with the mainline kernel. There seems to be some fear that Big Powerful Google will attract more device-makers to write Linux drivers (which is a great thing), but said drivers will be written specifically for "Android Linux" and not everybody-else Linux (which is not so great) because who wants to, for example, write and maintain "wakelocks" and "no-wakelocks" versions of their drivers separately? This doesn't seem like an unreasonable prediction if Google is really dumping mainline Linux ("but we can still be friends, and that's okay..."). Sure, even if Google ends up just "throwing code over the wall" where mainline developers can sift through it and work on the task of translating the drivers to work on everybody-else-Linux, that IS much better than nothing at all. But it kind of hurts compared to what a more unified collaboration might accomplish. And after all this, I'm STILL not entirely sure why I, personally, even care, but I do...
Please excuse one more followup... Posted Feb 4, 2010 6:31 UTC (Thu) by mogul (subscriber, #3163) [Link]
Well spoken. I'm in the same situation with respect to personal involvement (and haven't even posted comments on LWN despite years of reading), and am bothered by the same dismissive elements in the posts above.
Fragmentation Posted Feb 4, 2010 20:32 UTC (Thu) by andypep (subscriber, #33588) [Link]
I agree with you, and I'm possibly even less concerned at an intimate level than you are.
What bugs me is the uneasy feeling that Linux may fail in the same way that Unix did - by being developed independently by a number of organisations that lead to a lack of standardisation and fragmentation. The GPL was the best bet to try to stop this happening by insisting on passing the modifications back into the pot, but this has to be de in a timely and considered manner if it is to continue to work that way. Previous forks have sorted themselves out in the market place - but it looks here like the kernel has developed two large separate markets that will go their different ways.
That bothers me in the medium to long term.
"Linux people" Posted Feb 4, 2010 4:21 UTC (Thu) by Epicanis (guest, #62805) [Link] I swear that unless someone indicates they want me to reply to something I'm going to digitally shut up here after this post, but that "Linux people" comment is bugging me. "Wow, what is it with Linux people[...]" You're the "Android Open Source and Compatibility Lead" and obviously have some role in Android development that puts you in a place to understand at least some of the technicalities of Linux kernel development - certainly more than me, at least. Despite this, you've just gone to the effort of coming here into the midst of a bunch of "Linux people" worried about potential compatibility issues between mainline Linux and Android Linux and implicitly declared yourself "not a Linux person". I don't get it. The "[Linux|Open Source] people are impractical for caring about compatibility and licensing and patents and stuff that consumers don't care about" meme seems to pop up a lot lately. Most of the time it's just obvious annoying trolling, or sometimes a blogger or "pod"caster who appears to think that saying so will buy them more "mainstream" credibility, but seeing even small signs of it from the "Android Open Source and Compatibility Lead" is vaguely disturbing. Please tell me this is just a matter of "posting while ticked off" and not really the way Google feels about things...
I'm worried. Posted Feb 4, 2010 15:02 UTC (Thu) by mgross (subscriber, #38112) [Link]
The wake lock patch isn't too objectionable "in theory" when it stayed as an alternate way for calling pm_suspend, but changing the semantics of /sys/power/state and the addition of the /sys/power/wait_fp_* file nodes to signal the surface flinger to start/stop with the drawing *is* nasty, and represents a significant fork.
I would argue that these are the most dangerous changes. With this a kernel for android is not compatible with a gnu/linux root file system (for power management).
So it was bad enough that an android root file system couldn't run on a normal linux kernel (missing binder, early suspend fb, wakelocks) but now if you run an android kernel with a gnu/linux user space you can't suspend.
Also, if you pull the omap or msm kernel git trees and do a git format-patch v2.6.29 (their baseline versions), you'll see 7240 patches for omap and 1083 for msm
Now grep those patches for wakelock and early suspend to see how may places the wake locks are finding themselves. Thus showing how wrong my "in theory" comment above was.
From a kernel developer perspective I fear we've took too long to "get it". This is a big forking point. Something needs to be done or most future Android devices will be stuck on a 2.6.29 base using old tool chains, with incompatible driver enabling for Si's device vendors and integrators to support.
its not just a problem for Linux, it will more than double the cost of enabling and support for platform enabling to for the Si's and device manufacturers.
It adds economic pressure to the device ecosystem. Making it more expensive to develop and sell new hardware. (wait, that is good for my stock.... just kidding...a little)
I have no worries. Posted Feb 7, 2010 8:59 UTC (Sun) by swetland (subscriber, #63414) [Link]
We've already moved to 2.6.32 (final cleaned up branches should be online this week) and will continue to track and rebase up to newer kernels, as we have since we started back with 2.6.14.
Arve is planning on once again reviving his push of wakelock patches to linux-pm (I guess this'll be rewrite #5) -- the last one stalled out after somebody told us we need to use read/write instead of ioctl()s and it was unclear how hard a requirement this was and if it really was an improvement.
The version he's been cleaning up for going-to-mainline discussion is not fully folded into our tree, since it keeps getting reworked based on feedback on the linux-pm list. We'll stick with what we have now until we can sort out something that everyone's happy (more or less) with.
I think if we can find some common ground on wakelocks, the rest really becomes a non-issue. The SoC specific code then is no different than any other kernel code, and the android generic drivers (binder, ashmem, logger, etc) have always been standalone components that, if necessary, could be maintained as a sidecar patchset.
Some things like the binder could be replaced -- we'd need somebody to completely replace the userspace infrastructure that depends on it, in a way that doesn't cause a performance or stability regression, but if somebody *had* such a set of patches and they survived automated and field stress testing, we could seriously talk about dropping the binder driver entirely.
- Brian
|
|
||||||||||||