| |||||||||||||
Greg Kroah-Hartman: Android and the Linux kernel communityGreg Kroah-Hartman: Android and the Linux kernel communityPosted Feb 4, 2010 7:38 UTC (Thu) by cdibona (subscriber, #13739)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
And again. And again. And again, for many years to come.
(Log in to post comments)
Greg Kroah-Hartman: Android and the Linux kernel community Posted Feb 4, 2010 20:23 UTC (Thu) by rahvin (subscriber, #16953) [Link]
But the beauty of getting it all into the Mainline kernel is that switching vendors becomes trivial. And the best part is that you can tell the hardware vendor to do the work to get it into the kernel before you ever even consider using the hardware. Not only can the vendor produce better code for their hardware, but once it's all upstream it's trivial to support if you are using mainline Kernels.
It's a seriously big mistake Google is making by forking. The long term effort will grow exponentially over time until the effort to maintain will exceed the benefit at which point the company will dump the project. If you don't believe me, look at Redhat's financial reports and see how many millions they spend to back port security fixes to kernel versions that are still in their long term support tree. Although the average phone isn't very old there are people that keep them until they break (I've seen 5-6 years old personally). RedHat spends millions keeping 3 year old kernels workable, when you have to support kernels that are that old you will see the real expense of the path you are taking. What I fear is that once you get to that point google will just decide it's not worth it anymore and abandon the whole thing. I actually think that's pretty likely personally.
Your posts make it apparent you don't realize the long term consequence of forking, particularly something as massive and important as the kernel. When Verizon or ATT sues Google for billions because someone used a known security vulnerability in an Andriod kernel that some cracker used to shut down the cellular system (and as a consequence someone couldn't dial 911 and then died) how will you defend the path you've chosen when you sit on the witness stand?
Some clarification on "the Android Kernel" Posted Feb 7, 2010 8:48 UTC (Sun) by swetland (subscriber, #63414) [Link]
There seems to be a lot of confusion here.
We maintain a set of patches on top of Linux, which we periodically rebase to the latest released Linux kernel. We've been doing this roughly every other kernel release since about 2.6.14. This week we're finalizing our move to 2.6.32 for the Android "Froyo" release, and we'll likely be on .33 or .34 for "Gingerbread".
These patches fall roughly into four buckets:
We've been publishing this code since fall of 2007, when the Android SDK was first released. We try to do almost all our work in the open (for generic drivers and SoC support), with only very product/board specific drivers being delayed until products are announced or shipped.
We certainly would love to get stuff upstream, but it's most useful if we can actually build upstream so it'll work with the Android userspace otherwise we're stucking maintaining patches for that anyway.
We realize, of course, that not everything we do is going to fit with the upstream view of the world, but I think this is a two way street -- being simply told "throw that all out and start over" is perhaps not the best way to encourage people to contribute.
- Brian
Some clarification on "the Android Kernel" Posted Feb 7, 2010 11:44 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
It is your decision to ship with changes that has not been send upstream
before the product even ships and long after that as well and it is often the case that if there are userspace dependencies on such out of tree patches it will come back to bite you
Even now code is being dumped over all the wall in large chunks rather than
Some clarification on "the Android Kernel" Posted Feb 8, 2010 6:04 UTC (Mon) by swetland (subscriber, #63414) [Link]
Shipping great products will *always* be higher priority than getting full buy-in from upstream or getting all patches reviewed. There's no way we can tie our ship schedules to an external process like that and accomplish the hard deadlines involved in shipping successful consumer electronics / mobile devices. Realistically, we'll always ship based on at least a couple-month-old kernel due to the time involved in QA, regulatory testing, and qualification for these kinds of devices.
That said, keeping up to date with mainline is extremely important to us -- thus we've rebased many times between 2.6.14 (first internal kernel work) and 2.6.32 (latest), to track mainline, as opposed to sitting on some years-old release forever.
And the best way to keep up to date is just to be in the mainline kernel, so we want to get there and will work to get there, as we can, around other schedule, staffing, etc limitations that often make it difficult.
Some clarification on "the Android Kernel" Posted Feb 18, 2011 6:00 UTC (Fri) by tchalvak (guest, #72984) [Link]
Thank you for explaining the necessity of your approach. With a goal like android phones in mind, I expect it is certainly necessary to make some compromises, it's just a question of how short the turn-around time can be to compensate for compromises.
I felt compelled to create an account to comment on the unfortunate level of hostility and lack of willingness to start useful, civil dialog ppreviously shown in this thread.
Android (from a user perspective) is a breath of fresh air in the operating system ecosystem, and I eagerly await the day that it becomes integrated more fully with desktop linux, so that everyone gets the benefit of both. I expect willingness to work together on what may be difficult technical solutions is the only thing that will get us there.
--posted via my android phone
|
|||||||||||||