Forgot your password?
typodupeerror
Google Operating Systems Linux

Android and the Linux Kernel Community 354

Posted by timothy
from the cathedral-in-the-bazaar dept.
An anonymous reader links to Greg Kroah-Hartman's explanation of a rift (hopefully mendable) in the development culture of Google's Linux-based Android OS and the Linux kernel itself. "As the Android kernel code is now gone from the Linux kernel, as of the 2.6.33 kernel release, I'm starting to get a lot of questions about what happened, and what to do next with regards to Android. So here's my opinion on the whole matter ..."
This discussion has been archived. No new comments can be posted.

Android and the Linux Kernel Community

Comments Filter:
  • Google (Score:4, Interesting)

    by sopssa (1498795) * <sopssa@email.com> on Wednesday February 03, 2010 @04:25PM (#31014340) Journal

    Because Google doesn't have their code merged into the mainline, these companies creating drivers and platform code are locked out from ever contributing it back to the kernel community.

    Google shows no sign of working to get their code upstream anymore.

    Oh come on, was it really a surprise to anyone that Google does only care about OSS when it suits them and drops out instantly when it doesn't. All of their own sites, business and back-end technology is just as closed as Microsoft's.

    I see someone coming along and saying "but they contribute to open source!". Sure, they do, they release little snippets of code and open source those products they base on OSS code because they have to by GPL. One could seriously argue if their open sourcing efforts are making better open source community in general, or not. Like TFA states, their ignorance has caused more turmoil than ever before in Linux land. Companies are obviously going to create support and drivers for Android-branch of Linux kernel, but cant contribute the same code back to real Linux kernel. And possibly never will because it costs them too much work, money and time. Even those companies that previously did develop linux drivers. That's not harming Linux and OSS community?

    Get off your lazy ass and see what's really happening.

    • by Colin Smith (2679)

      That's not harming Linux and OSS community?

      No, it isn't, because there is open competition from other vendors. The only group it's harming is Google and those companies dumb enough to buy into Android for their future.

       

      • Re: (Score:2, Interesting)

        by sopssa (1498795) *

        The only group it's harming is Google and those companies dumb enough to buy into Android for their future.

        Google has a major advantage here as one of the largest companies in the world, and those companies "dumb enough" are going to jump on Google's side because they have the market share.

        • Re:Google (Score:5, Interesting)

          by Colin Smith (2679) on Wednesday February 03, 2010 @04:46PM (#31014594)

          Google has a major advantage here as one of the largest companies in the world

          Nokia has the major advantage that they are *the* largest phone producer on the face of the planet and have *the* largest world market share by a large percentage. Google and particularly, Android are small fry in comparison, despite their size in other markets. Those companies jumping on Android are dumb because their horizon is limited to the US market and a single platform.

          For irony, Google "Maemo" and "Nokia N900".

          As I said, the only groups being hurt by this are Google and those dumb enough to rely on Android for their future, anyone else with a brain will take a look at the competition and more open platforms.
           

          • Google has a major advantage here as one of the largest companies in the world

            Nokia has the major advantage that they are *the* largest phone producer on the face of the planet and have *the* largest world market share by a large percentage.

            Yeah but that is mainly because of their hold on the market for cheap, dumb phones. The smartphone market is really a different beast now.

          • Re:Google (Score:5, Interesting)

            by Enderandrew (866215) <enderandrew&gmail,com> on Wednesday February 03, 2010 @05:54PM (#31015420) Homepage Journal

            What people seem to overlook is that Google wrote Android on their dime, opened it up, and then handed it over to the Open Handset Alliance, which has companies like Nokia on the board. Google does not own and control Android. The Alliance does.

            And how is Android not open? The entire thing is FOSS.

            • Re:Google (Score:5, Insightful)

              by Microlith (54737) on Wednesday February 03, 2010 @06:58PM (#31016340)

              And how is Android not open? The entire thing is FOSS.

              I wondered that myself when looking into the N900, and the explanation as to why Android is not open is because while it is Open Source, it does not have an open community.

              If you look at the OHA FAQ, they explain why an open platform is good for everyone EXCEPT the end-user. Unless you mistake who your customer is, you'd realize that the end-user's input is just as important as those who apply your OS to their device. Both the OHA and the cell vendors make that mistake, as the OHA thinks the user of Android is the handset maker, who themselves think their customer is the carrier. The only true customer is the person who pays for and uses the device in the end, and they should be able to have input into their device and its OS should they care.

            • The simple solution (Score:4, Interesting)

              by symbolset (646467) on Thursday February 04, 2010 @03:41AM (#31019680) Journal

              I'm hiding the easy answer here deep in the thread under your question.

              Google has Android slates (tablet format ARM-powered machines). If Google took 1000 of them ($400K worth) and just gave them to select Kernel developers (several each) to do with what they would, the problem would solve itself. The Kernel developers would adapt their preferred distro to work on the first slate they had, and they'd keep the rest to work as they were intended until it limited them - and then they'd want to break the limit by improving the Android code, which they would then want back in the Kernel tree because they would want their improvements to persist. It's all about motivation, and you motivate a Kernel geek with cool tech he wants to continue to use.

              HP did this. Why do you think Kernel.org runs on HP servers and has for many years? It's because HP donates servers strategically, and yields huge benefits therefrom.

            • Re: (Score:3, Interesting)

              by Miamicanes (730264)

              > And how is Android not open? The entire thing is FOSS

              (cringes, wrings hands for a while, coughs a bit, then sighs)

              "Android" might be "open", but people fighting on the Android front lines and trying to run open builds without the blessing of HTC and their carrier might politely beg to differ. To date, nobody has been able to independently build a fully working 2.6.29 kernel for ANY CDMA Hero phone that shipped with Android 1.5 (Sprint Hero, Sprint Samsung Moment, Verizon Droid Eris). Without a 2.6.29 k

          • Re: (Score:3, Informative)

            by unfunk (804468)

            As I said, the only groups being hurt by this are Google and those dumb enough to rely on Android for their future, anyone else with a brain will take a look at the competition and more open platforms.

            Newsflash: Consumers don't care about whether Google's playing nice with the Linux community or not.

        • Re:Google (Score:4, Insightful)

          by Score Whore (32328) on Wednesday February 03, 2010 @04:54PM (#31014690)

          This is some seriously poor logic. Consider for a moment GM. In 2008 they were the 4th largest company in the United States. By your logic it would be ideal to attach your company's future well being to GM. Now consider how well that worked out for over 1000 GM dealers, hundreds of parts suppliers, etc. See how that turned out. For the record, Google was #117 in 2008.

    • Re:Google (Score:5, Funny)

      by killmenow (184444) on Wednesday February 03, 2010 @04:35PM (#31014462)

      Apparently Google employees have mod points today.

      • Re: (Score:3, Funny)

        by dangitman (862676)

        Apparently Google employees have mod points today.

        Well, duh. Google employees always have mod-points. Where do you think slashdot gets them from in the first place?

    • Re: (Score:3, Insightful)

      by CSHARP123 (904951)
      It is called Embrace, Extend and Extinguish. I thought it only applies to MS. Well I think, Do no Evil is gone through the window :)
      • Re:Google (Score:5, Informative)

        by gyrogeerloose (849181) on Wednesday February 03, 2010 @04:56PM (#31014708) Journal

        It is called Embrace, Extend and Extinguish. I thought it only applies to MS. Well I think, Do no Evil is gone through the window :)

        Well, we know what Steve Jobs said [wired.com] about Google's "Don't Be Evil" mantra--"It's bullshit." Or, "a load of crap," depending on your source.

        • Re: (Score:2, Insightful)

          by exomondo (1725132)

          Well, we know what Steve Jobs said [wired.com] about Google's "Don't Be Evil" mantra--"It's bullshit." Or, "a load of crap," depending on your source.

          Is that actually based on anything though? You have to remember that 'evil' is a point of view and when a company gets that large and that diversified obviously they are eventually going to step on the toes of someone who has a different interpretation of what is 'evil'.

          • Is that actually based on anything though? You have to remember that 'evil' is a point of view and when a company gets that large and that diversified obviously they are eventually going to step on the toes of someone who has a different interpretation of what is 'evil'.

            Just so we understand each other, I'm not necessarily advocating Jobs's position, just quoting him. But I think that what you're saying is pretty much in line with what Jobs said, which is not that Google is evil, only that "Don't Be Evil" isn't really applicable.

          • Re:Google (Score:5, Interesting)

            by DangerFace (1315417) on Wednesday February 03, 2010 @05:41PM (#31015242) Journal

            Well, we know what Steve Jobs said [wired.com] about Google's "Don't Be Evil" mantra--"It's bullshit." Or, "a load of crap," depending on your source.

            Is that actually based on anything though?

            Yes - it's based on one rich guy being annoyed that another rich guy threatened to take some of his richness. From the linked article:

            On Google: We did not enter the search business, Jobs said. They entered the phone business. Make no mistake they want to kill the iPhone. We won’t let them, he says. Someone else asks something on a different topic, but there’s no getting Jobs off this rant. I want to go back to that other question first and say one more thing, he says. This don’t be evil mantra: “It’s bullshit.” Audience roars.

            Steve Jobs wasn't making some deep point about Google's manipulation of FOSS, he was just ranting about unfair competition (for 'unfair competition to Apple in the eyes of Steve Jobs' read 'Giant, friendly, happy-go-lucky Silicon Valley company treating design and user experience as important'). He may as well have just complained that Google won't share their toys.

            • Re: (Score:3, Interesting)

              by Anonymous Coward

              Steve Jobs wasn't making some deep point about Google's manipulation of FOSS, he was just ranting about unfair competition (for 'unfair competition to Apple in the eyes of Steve Jobs' read 'Giant, friendly, happy-go-lucky Silicon Valley company treating design and user experience as important'). He may as well have just complained that Google won't share their toys.

              To be fair, there's a little more to it than that. Eric Schmidt, the CEO of said "giant, friendly, happy-go-lucky Silicon Valley company," was s

              • Re: (Score:3, Interesting)

                by oztiks (921504)

                You know, this might explain the giant hole between the original release of iPhone and the release of Android.

                Apple created the SmartPhone market place and can carry the "I was here first badge". Of course we had other SmartPhones prior to this but the market was fairly restricted to business use not really domestic (everyone one from 16yr old kids to 70+ year old retirees use iPhone).

                And I'll say it again, hoping i wont get marked a troll for stating a true but negative POV, but Google I believe missed the

                • Re: (Score:3, Informative)

                  by salesgeek (263995)

                  Wrong. Let's not act like a product category that had been around for 10 years prior to iPhone was suddenly created by Apple. Apple did not create the smart phone. They did not even define the product:

                  Palm, Blackberry and Microsoft (to a lesser extent) defined the product. Apple came out with the best model in the 2008 model year. That is the extent of the achievement, and to give Apple more credit is simply an insult to the people that created iconic products like the Blackberry, Treo and to a lesser de

        • Re:Google (Score:5, Insightful)

          by ajs (35943) <ajs@@@ajs...com> on Wednesday February 03, 2010 @06:08PM (#31015632) Homepage Journal

          Google's "Don't Be Evil" mantra--"It's bullshit."

          What's sad is that, here on Slashdot, we run with the worst possible interpretation of everything.

          So, what started as one non-Google developer deleting some Android-specific drivers from Linux (mind you, leaving in massive amounts of upstreamed work from Google, this is just the small Android-specific bits) becomes "Google is abusing the open source community and is now evil."

          Sad, just sad.

        • Re:Google (Score:5, Insightful)

          by hannson (1369413) <hannson@gmail.com> on Wednesday February 03, 2010 @08:51PM (#31017474)
          Yeah Steve's totally right there, Google definitely should have asked Apple for permission before developing the Nexus One or Android... just like Apple asked all the other phone companies for permission when developing the iPhone or the MP3 player manufacturers when developing the iPod..... oh wait... what a dick!
    • Re: (Score:3, Insightful)

      by ClosedSource (238333)

      The problem is the idea of a single code base that will satisfy all needs is a pipe dream and always will be. Developers may have to do some extra work to write appropriate drivers for both trees. Welcome to the real world.

    • No, I don't think so (Score:5, Interesting)

      by Concern (819622) * on Wednesday February 03, 2010 @05:08PM (#31014840) Journal

      Google has frankly set a new standard as far as how companies can become very successful by embracing the open and free software communities. I honestly don't think you can point to many other companies that are doing better, nor could you realistically expect to. In the mobile space, pretty much the next nearest competitor in terms of openness is Apple (Darwin, et al) - in other words, a joke. Meanwhile Google not only has a wonderfully organized system for playing with all the Android code, but a broad commitment across products. Look at Wave, for instance - wide, wide open, and very deliberately (because they know it cannot succeed any other way). Google has probably done more for Linux and its credibility than most other companies in the world.

      I think this is something totally different - a disagreement about direction between the mainline maintainers and Google's Android team. Corporate developers, even well-intentioned ones, have a conceptual hurdle to get over when someone Not Their Manager is telling them "you must spend x man-months refactoring your code thusly."

      Many, many companies have run into this issue with Linux (and other projects) before, and many will again. It usually goes something like this:

      Step 1: Whatever. We're Google. Am I going to rearrange my whole development roadmap to follow the directions of some whiny nerd in his mom's basement? LOL.
      Step 2: Oh. Crap. Wow it is kind of a lot work maintaining my own entire fork of the Linux kernel/KHTML/etc. all by myself.
      Step 3: Either A) capitulation - the last guy is fired or smacked with the clue stick, and the cooperation restarts, or B) a true fork. These usually stagnate and die, and are also riddled with bugs and security holes btw... unless, the fork is really more interesting than what it forked from, in which case, the community switches to the fork and justice is served.

      Often between Step 1 and 2, the maintainer will attempt to play a little corporate politics by embarrassing said middle manager in the media. By the way, this is pretty smart and it often works - especially with companies as large but otherwise savvy as Google, a slashdot story can jumpstart efforts to mend the rift by bringing more senior eyes on the problem. Cooperating is in everyone's interest, and they will realize it.

      • by Concern (819622) *

        Somehow I managed to forget Nokia for being more open than Apple - and arguably - Google. I guess because so few people use, or will likely ever use, their smartphones. :)

        • by marsu_k (701360)
          Yes, only 21 million of them [bbc.co.uk] were sold in the last quarter. (hint: USA != world)
          • by Concern (819622) * on Wednesday February 03, 2010 @05:45PM (#31015282) Journal

            I can't find anything yet that actually gives N900 or Maemo sales figures. Your link does not - I am all ears if you have something. Something tells me that Nokia isn't anywhere remotely near selling 21 million devices truly comparable to iphone or android in Q4. "Converged mobile device volumes" is very carefully worded and my guess, careful weasel wording is the only way the can come up with a number so impressive-sounding.

            Apple has only shipped 75 million [gizmodo.com] iphone and ipod touch devices combined worldwide, and something like 8.7 million iphones in Q4. [fiercewireless.com] So if Nokia "true" smartphones were outselling Apple smartphones by such a margin, in any way shape or form, I think that would be bigger news, no?

            I think this confusion comes from Nokia labelling any $50 gadet of theirs with a dime-store web browser and a music player as a "converged mobile device." But even in this case I should have qualified my remarks as referring to smartphones, rather than just "mobile."

      • Option B (Score:2, Interesting)

        by zogger (617870)

        Has there ever really been a serious option B effort to just pick a time and do a major kernel fork and maintain it forever by any company as large as google, with their level of developers and resources/cash behind them? Any precedent there?

        • Yes, Redhat (Score:5, Interesting)

          by Concern (819622) * on Wednesday February 03, 2010 @06:05PM (#31015590) Journal

          "Redhat Enterprise Linux 5" is essentially a massive kernel fork at 2.6.18. Redhat is the most plausible contender for doing this, since they employ a really significant number of the world's kernel devs, including Alan Cox (until last year). That split was even acrimonious at times IIRC. But then again, you can just call it similar to Canonical's LTS - people choose whether to go with a version of something that's more or less mature - and most distros going with the "more mature" option frequently cheat and backport all kinds of things in the meantime (with greater and lesser success).

          Depending on who you ask, RHEL can be more risky than mainline. I've definitely had RHEL panics take down production, only to later discover linux kernel bugs that had been fixed in mainline for a while, but that redhat hadn't backported to their ancient linux fork. But then again, people get burned going the other way all the time too. I don't know if anyone's really independently studied what's ultimately safest. My guess is that you are usually safest inside the biggest crowd - i.e. closer to mainline - but not too near the very latest version.

    • Re:Google (Score:4, Insightful)

      by shutdown -p now (807394) on Wednesday February 03, 2010 @05:17PM (#31014940) Journal

      Sure, they do, they release little snippets of code and open source those products they base on OSS code because they have to by GPL.

      Erm, no. While I don't consider Google to be a particularly charitable organization, they do regularly open source their products (though mostly minor ones, as you rightly pointed out) when there is no legal obligation on them to do so.

      The reason for that is perfectly clear, too: it strengthens the image of Google as both "geeky" and "open" tech company, which are both important parts of Google's public image.

      • Re:Google (Score:5, Informative)

        by Temporal (96070) on Wednesday February 03, 2010 @05:57PM (#31015460) Journal

        Erm, no. While I don't consider Google to be a particularly charitable organization, they do regularly open source their products (though mostly minor ones, as you rightly pointed out) when there is no legal obligation on them to do so.

        The reason for that is perfectly clear, too: it strengthens the image of Google as both "geeky" and "open" tech company, which are both important parts of Google's public image.

        It's not just public image. There's also the fact that Google is a company full of geeks, many of whom are open source fans in their own right.

        I was primarily responsible for Google releasing Protocol Buffers [googlecode.com]. I did it not for the sake of improving my employer's public image, but because I thought it was a useful tool that should be shared, and those around me agreed. Because of the bottom-up nature of decision making at Google -- and given that I was willing to do the work -- I had no trouble pushing this through.

        So yeah, it's pretty upsetting to me to see people say things like "Google does only care about OSS when it suits them and drops out instantly when it doesn't.". This kind of statement completely misunderstands how Google even works. This just isn't the kind of company where orders comes down from executives on high with the only motive being profit -- anyone who thinks otherwise obviously doesn't work here.

        Honestly, I think the main reason we haven't released more stuff is because it's kind of a lot of work (as I have learned). Dumping code over a wall does not please the open source community -- you have to maintain it; document it; test it on a zillion platforms; answer e-mail from people who think they are not just entitled to your code, but are doing *you* a favor by using it; review patches from college kids who don't really know what they're doing; etc.

        (Oblig. disclaimer: These are my own personal opinions; I am not authorized to speak for my employer.)

        • Re:Google (Score:5, Funny)

          by adamofgreyskull (640712) on Wednesday February 03, 2010 @07:46PM (#31016844)

          Because of the bottom-up nature of decision making at Google

          (Oblig. disclaimer: These are my own personal opinions; I am not authorized to speak for my employer.)

          So just authorise yourself, right? ;)

      • Re: (Score:3, Insightful)

        by Enderandrew (866215)

        Please spend two minutes looking at Google.org.

    • by jeffmeden (135043)

      So sponsoring the "Summer of Code" doesn't count as contributing? Seeing as how they have paid for development time on hundreds (if not thousands) of good projects? What have you done for Open Source lately?

      Yes, their behavior with regard to the code going into their products does not really embrace the open source model, but given the constraints they are under to protect their core business IP, can you blame them?

      It seems like the best thing that can happen is for Google to maintain the Android changes

    • Re:Google (Score:5, Interesting)

      by Enderandrew (866215) <enderandrew&gmail,com> on Wednesday February 03, 2010 @05:51PM (#31015370) Homepage Journal

      They don't support OSS when it doesn't suit them?

      They pay the salaries of guys like Andrew Morton and then cut him free to work on Linux as he sees fit, basically just answering to Linus.

      They pay for projects like the Summer of Code, paying for the development of projects they don't use internally.

      They released patches for projects like Wine well before they were using Wine in any releases of their projects.

      You claim they only release code when they have to. They were never required to create an OS. Are you aware the Chromium browser code is BSD released, right? It wasn't like they just wanted to build upon some GPL project and then were required to stick with GPL. They build a whole new browser, and opened it up BSD so anyone can use the code however they want. How is that closed?

      Look what they're doing with Wave. They developed an entire protocol from the ground up. The protocol and all the server code is open. They could have tried to patent the protocol and charge for licensing. They're just releasing the whole thing and telling people to do whatever they want with it completely for free.

      What about protocols like SPDY they wrote from scratch and released for free? What about their various hardware designs for power supplies they've released for free? These are things that give them a competetive edge. If anything, most people would argue it hurts them to give them away for free, but still they do it. They rarely get credit for how many things they open up. And yet the very communities Google helps finance and take care of turn around and slam Google. Do you realize who your allies are in the FOSS world?

      You claim they're just as closed as Microsoft?

      Pure lies and trolling. Seriously, shut the hell up.

    • Re:Google (Score:5, Insightful)

      by ajs (35943) <ajs@@@ajs...com> on Wednesday February 03, 2010 @05:53PM (#31015394) Homepage Journal

      Oh come on, was it really a surprise to anyone that Google does only care about OSS when it suits them and drops out instantly when it doesn't. All of their own sites, business and back-end technology is just as closed as Microsoft's.

      Point 1) how is not pushing to mainline code "dropping out" of open source development exactly?

      Point 2) The Common Android Kernel tree [kernel.org] is browsable, and looks to be fairly easy for anyone to take advantage of. The complaint here seems to be that Google isn't putting in enough work to merge their Linux kernel changes into the mainline, not that they have failed to release anything in a usable way. I find it somewhat disingenuous to slap down an open source contributor for failing to do our work for us.

      Point 3) Microsoft's services are just as open?! Great, where is Microsoft's instructions on how I can export all of my data from all of their services in open formats? Google provides that [dataliberation.org] so I'm certain you're aware of where Microsoft publishes such information as well... Oh and while you're at it, how many open source projects do Microsoft projects contribute to? Python, Linux, and dozens of other existing projects get updates from Google and they've released more open source software of their own making than anyone else.

      So, what company have you been watching that confused you so badly that you thought Google wasn't the single largest benefactor open source has?

    • by twistah (194990)

      Did you forget about the Google Summer of Code and multiple other projects where they basically fund the development of OSS tools?

  • by Jorl17 (1716772) on Wednesday February 03, 2010 @04:28PM (#31014370)
    "Because of this, Google has now prevented a large chunk of hardware drivers and platform code from ever getting merged into the main kernel tree. Effectively creating a kernel branch that a number of different vendors are now relying on."

    That's all. It's obvious that Google doesn't care about it that much. And yet nobody demanded them to do so -- if Google wants it its own way, why shouldn't it be able to?
    I may be a crazy open-source lunatic, but I am tired of all of this "It's a world conspiracy against Linux"-thing. Let's get a grip, talk less and code more.
    • Re: (Score:3, Insightful)

      by godrik (1287354)

      I don't think he is seeing this as a conspiracy against linux. He is just saying that some work may have to be done twice (because merging is not feasible) which is really bad for everybody. no one wants to maintain 2 code base.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        So then maybe they shouldn't have kicked the android code out of mainline in the first place?

        • by gstoddart (321705) on Wednesday February 03, 2010 @04:42PM (#31014542) Homepage

          So then maybe they shouldn't have kicked the android code out of mainline in the first place?

          If it created code dependencies that nobody buy Google could compile against, it's got no business in the mainline -- it effectively breaks the kernel for everyone else.

          This isn't a matter of getting voted off the island because they don't like your features -- it's about making something which was incompatible and people deciding that it had to go.

          • You can use Android, but you're now dependent on Google for maintenance, bug-fixes, and trusting that they don't include any evil bits.
            • Re: (Score:3, Informative)

              by AndrewNeo (979708)

              Hardly. Nobody's forcing you to run their binaries on your phone. You can still compile the kernel and other applications from code, forked or not.

            • Re: (Score:3, Interesting)

              by Enderandrew (866215)

              You do realize that Google does not own nor control Android, right?

              Google handed Android over to the Open Handset Alliance the moment they unveiled it. There are several large companies (like Nokia and Motorolla) who take part in that alliance.

        • by advocate_one (662832) on Wednesday February 03, 2010 @04:44PM (#31014576)

          So then maybe they shouldn't have kicked the android code out of mainline in the first place?

          it never made it out of staging into mainline... it wouldn't build as there were items Google never released that it was dependent upon.

          • by minsk (805035) on Wednesday February 03, 2010 @05:09PM (#31014852)

            it wouldn't build as there were items Google never released that it was dependent upon.

            Are you sure that statement is true? It seems inconsistent with other information posted here, and in the LWN discussion.

          • Re: (Score:3, Informative)

            by jeremyp (130771)

            How is this +5 informative? It's completely false.

            The reason it didn't make it to mainline is because the Google code was reviewed and found to have problems that stopped it being accepted into mainline. Because there are user space items in Android that would be affected, only Google could make the changes without breaking Android.

            Think about it, if you were unable to build the Android kernel because Google were withholding stuff, it would be in direct violation of GPL v2. Do you see Greg KH complaining

      • Re: (Score:2, Interesting)

        by Jorl17 (1716772)
        Well, I didn't say he meant that either. I'm talking about the great fuzz around these issues. Everywhere I go there's someone trying to give his/her side of the "conspiracy against Linux", whereas I think that there is no such thing. So what if it can't be merged back? If it can't, it can't -- get something better and don't stay up all night banging the ceiling and complaining (if you get what I mean).
        I would like to see people looking at what Google did and say: "Oh well, it's their choice and I can't do
    • by Lumpy (12016) on Wednesday February 03, 2010 @04:39PM (#31014510) Homepage

      Nothing is stopping people from porting android to use a standard Linux kernel.

      Honestly It's a two way street, and I doubt that google looked at the Linux guys and told them to go fornicate with themselves.

      Google does releases on their own schedule. Being someone that is deep into Android guts on the x86 level for a project of my own (android based car stereo) I am frustrated at them not releasing the latest version, but I can either sit and while like a baby, or take what I got and build on it.

    • not quite... (Score:5, Insightful)

      by RingDev (879105) on Wednesday February 03, 2010 @04:46PM (#31014596) Homepage Journal

      This isn't about some anti-Linux conspiracy, it's about conflicting business interests.

      Google has made modifications to make their software work. Those modifications can not be integrated as is with the kernel. Cleaning up their open source code can be done, but their internal closed code would likely also need modifications to account for that cleanup. So for Google, merging their code would likely be expensive and require extensive testing and a large download and upgrade system for all of the live phones.

      On the other hand, companies that are developing drivers and software that depend on the new kernel are now hosed because the kernel is no longer exposed as part of the Linux kernel. So they have to deal directly with Google for any changes to their kernel, and if they also want to release their products for other Linux platforms, they have to re-engineer much of the os-interaction functionality. Obviously a pricey situation for them.

      If Google updates their code to get it into the kernel, it makes it cheaper and easier for other developers to work it, but it costs them money. If they don't then it costs the developers more money.

      -Rick

      • Re: (Score:3, Insightful)

        Nice summary.

        I'd like to add: Developers, developers, developers, developers. Google should spend that money. Consider it an investment in your platform -- it makes it that much more attractive to other developers.

    • by tixxit (1107127)
      Huh? I think the point he was driving at was that these companies will now have to support their own drivers, with no chance of letting the community take over. If they could merge their drivers into the main linux kernel, then other developers can take on the task of migrating it to new linux versions, improving it, and creating security fixes. Since they can't do this, they (or Google) will now be responsible for maintaining the driver, always.
  • by Rene S. Hollan (1943) on Wednesday February 03, 2010 @04:43PM (#31014544)

    You don't merge new features into a robust low-level code base.

    You merge support for abstractions the new features rely upon into the low-level code base, and build on them.

    Make a case for kernel support of the "new lock" and "security model" independent of Android's reliance on it, and remove as many of the Android drivers using these facilities OUT of the main tree. IMHO, drivers really don't belong there, but should be available in "driver package sets" aggregated by distro providers.

    • Re: (Score:3, Insightful)

      Kernel development isn't driven by the product needs but by egos people maintaining it. In that sense it is no different to any closed source kernel. The only option to get things done quickly is to fork it and then hope to get it merged later. Linus isn't exactly known as "accommodating" and "reaching out" individual and merging code upstream isn't exactly a priority on Google product schedule so there.
  • by chrisd (1457) * <chrisd@dibona.com> on Wednesday February 03, 2010 @04:51PM (#31014662) Homepage
    If you head over to LWN, we've already gone back and forth on this a bit. http://lwn.net/Articles/372419/ [lwn.net]. The short form is that if they don't like how we use the kernel, we're unlikely to be accepted upstream. It's all still released as source code to the world, but the mainline is not interested in most of what we've with to the kernel.
    • by VON-MAN (621853)
      Ok. But as far as I know, all new code has to be made fit for the kernel before merging, and not the other way around. So I wonder: can somebody else -outside of Google- cleanup and merge your stuff?
      • Re: (Score:3, Informative)

        by Eunuchswear (210685)

        Might be rather hard to "clean up". Back in 2008 Mathew Garret wrote: [livejournal.com]

        Google was going to be an interesting case of a large company hiring people both from the embedded world and also the existing Linux development community and then producing an embedded device that was intended to compete with the very best existing platforms. I had high hopes that this combination of factors would result in the Linux community as a whole having a better idea what the constraints and requirements for high-quality power m

    • by Anonymous Coward on Wednesday February 03, 2010 @05:25PM (#31015034)

      That's completely disingenuous. Everyone agrees that the problems Android needs to solve should be solved. The kernel community simply disagrees with *how* Google solved the problems. Long ago Google could have asked "we need to optimize power usage by doing agressive suspend" and then worked with the kernel community to get a solution that everyone was happy with.

      But instead, Google went off into a corner, created their own solution behind closed doors that nobody in the kernel community likes and now it can't go upstream.

      It's not about "how we use the kernel", it's about how you coded things in isolation then expect everyone to be ecstatic with the result despite the fact that the gatekeepers never had any input into the design.

      • by Flavio (12072) on Wednesday February 03, 2010 @05:37PM (#31015184)

        But instead, Google went off into a corner, created their own solution behind closed doors that nobody in the kernel community likes and now it can't go upstream.

        No one in their right mind is going to start a lengthy debate with kernel developers when they have a deadline to meet and a product to ship.

        In the industry, getting things done on time is priority #1. Google's implementation may not have been ideal, but it was delivered.

        • by WarlockD (623872) on Wednesday February 03, 2010 @06:09PM (#31015646)

          I think thats the whole issue here. Why does Goggle have to do any work to get "accepted" into the main kernel anyway?

          The android is an embedded device that works with a small subset of chips sets and devices. Why does it have to be in the main kernel to begin with? Is somone going to be shoving a PCI card in that thing? Heck, why does Google have to spend the weeks/months talking back and forth with the developers when they can get their own solution, that works just as well for them, in half the time?

          Talking about "giving back to the community" is all well and good, but I don't expect Google to sacrifice their profitability or deadlines just to make some members of the community happy.

          Lets be honest here though, all the code is in GPL so whats stopping someone else from doing the work?

          • by swillden (191260) <shawn-ds@willden.org> on Wednesday February 03, 2010 @10:36PM (#31018244) Homepage Journal

            I think thats the whole issue here. Why does Goggle have to do any work to get "accepted" into the main kernel anyway?

            They don't have to. If they don't, however, their codebase and the mainline codebase are going to grow further and further apart, which means that (a) the Android kernel will not be able to easily gain the bugfixes and enhancements that go into mainline and (b) the mainline kernel will not be able to easily take advantage of the drivers written for the Android kernel. Both will lose.

            I strongly suspect that what will ultimately happen, as has happened before, is that the Android devs will eventually realize that maintaining their own fork of the Linux kernel is just too much effort and that it is actually less work to do what's required to get their changes integrated into mainline. Many other companies have been through this same process and come to the same conclusion.

    • Re: (Score:2, Insightful)

      by diegocg (1680514)

      Which is perfectly fine, but it shows the autism in the google culture when it comes to working with people from outside. There're many companies working on Linux (doing more serious hacking than Android does), and they have learnt to interact with the Linux community when they want to add a feature. They ask maintainers what design they should follow to implement some feature. They listen, they write code, they get reviews, they make changes, they repost the patches. In other words, they interact with the

    • by Rene S. Hollan (1943) on Wednesday February 03, 2010 @06:42PM (#31016106)

      Okay. I got off my ass and actually looked at waitlock. It isn't, as I thought, a lock with a restoration of execution context when held, so that one can temporarily surrender other locks, and reacquire them. It is a lock on keeping the system out of various low-power states.

      Mainline has an (arguably, according to Google-folk, inefficient), lock on guaranteed service latency (low, medium, high?). and Google wants a lock on specific activity level abstractions (idle, suspend, etc.). Did I get that right?

      Well, if the present implementation is inefficient (a linear search...), fix that: use an AA-tree or heap, or something.

      I suspect the latency time guarantees are coarse at best and probably map to specific power states (idle, suspend, etc.) anyway. I think BOTH models should be supported (heck, you could always map levels to latencies in some tunable fashion, if you had to fake it: "responsiveness SUSPEND" vs. "hardware SUSPEND") but only because there are already standard abstract notions of what IDLE, SUSPEND, and POWEROFF are.

      What may have happened is that the existing implementation was inefficient, not quite fitting the expected model, and Google-folk found it faster to roll their own driven by time-pressure, instead of reworking the existing inefficiencies, thinking "heck, we can layer our API over the existing implementation later" and finding the models are more different than thought.

      Reconciling that is called "refactoring" and sometimes it breaks APIs as much as one does not want it to.

      Now, who has a vested interest in doing that?

      Google? Not really. They figure they can handle the overhead of a kernel fork, at least for a while.

      Mainline kernel devs? No. The existing model "works".

      I'll tell you who: Google's downstream customers. One of them will do it.

  • Technical aspects (Score:5, Informative)

    by shutdown -p now (807394) on Wednesday February 03, 2010 @05:26PM (#31015040) Journal

    "OMG fork!" and other political issues aside, I think it's interesting to look at the technical side of the problem. What is the exact nature of Google's changes to the kernel, why did they feel they need them, and are they actually a good idea or not? Can someone with kernel hacking experience enlighten us?

    I'm particularly curious after reading the comments on LWN [lwn.net], and specifically this [lwn.net]:

    Kernel developers (including other embedded developers who have achieved good power savings modes) don't believe that the Android way of doing things is good.

    and this [lwn.net]:

    The code could be mainlined if Google were willing to consider that their wakelock approach was suboptimal and adapt to a more reasonable one. ...

    The wakelock patches were first posted to the linux-pm list on the 13th of January 2009, which is just over a year ago. http://lwn.net/Articles/318611/ [lwn.net] gives a good overview of how they were received - there's basically no buy in, even from other developers in the embedded Linux field. ...

    the major sticking point (ie, wakelocks) were posted for public review a year ago and most of the substantive issues people had with them weren't addressed at all in the four months of intermittent discussion that followed. If the entire world suggests that you do something in some other way and you refuse to, that doesn't constitute a genuine effort to work with them. Nokia have managed to obtain the same level of power management without such invasive changes, so any assertion that wakelocks are required for Android to achieve its goals seem pretty baseless.

    So apparently the issue at the heart of this is a questionable design decision by Google.

    • Re: (Score:2, Insightful)

      by Aladrin (926209)

      I love how they blast Google for not being willing to meet halfway, but they're doing exactly the same thing.

      Not that there's actually anything wrong with -either- side, but if you're going to redress someone for something, you should make sure you're not guilty of it yourself first.

      • Re:Technical aspects (Score:5, Informative)

        by mjg59 (864833) on Wednesday February 03, 2010 @06:20PM (#31015818) Homepage

        Some background on this:

        Android is written to automatically attempt to enter a sleep state whenever possible. So, for instance, when your phone is in your pocket the hardware is suspended. You get an incoming call. You pick up a phone and press a button. The button press fully wakes up the phone. What stops the phone from suspending again?
        Wakelocks are Google's solution to this. Pressing the button takes a named wakelock. While any wakelocks are held, the phone will not go back to sleep. Once the call is complete, userspace can release the wakelock and the phone will suspend again.

        The problem here is that your wakelocks are tied to your userspace. Userspace needs to know which wakelocks the kernel takes in order to be able to release them. Which wakelocks you want will depend on how your platform is designed. Google have implemented the wakelocks they need to solve the problems they face - other vendors may wish to use different wakelocks. The end result is that you end up with a kernel that can only usefully run with a specific userland, and userland modifications require kernel modifications. It's broadly like saying that it'd be fine for some kernel drivers to require gnome and some others to require KDE.

        What's depressing about this is that it's an entirely unnecessary approach. You don't need the system to fully suspend. Modern ARM hardware supports something generally referred to as retention mode, which is where the hardware enters a power state equivalent to suspend without actually performing a full state transition. Rather than explicitly suspending, if there are no tasks to run then the kernel idle routine will put the CPU into this state. When a task is scheduled to run (either because of a timer or in response to an event), it runs.

        The stated objection to this is that applications can't be trusted to behave themselves. If I write an Android application that repaints itself by sleeping for a frame and then drawing, that'll keep waking up the CPU. In the wakelock scenario, the system isn't running and so this isn't a problem. In the retention scenario, it'll keep getting scheduled and battery life will suffer.

        There's two easy solutions to this. The first is to use the range timer functionality in the kernel. This allows applications to say "I want to sleep for about a second, and can afford this much inaccuracy". The kernel uses this to attempt to merge wakeups - if an application sleeps for a second and a millisecond later another application does the same, they can both be woken up at once rather than causing two wakeups. But we can also take this to more extreme lengths, for instance by changing the accuracy value to a millennium when the screen is turned off. The application won't get scheduled again until we receive a "wakeup" event and set the timers back. The second approach is even simpler - just SIGSTOP all non-system tasks when we'd otherwise release the wakelocks.

        So I wouldn't frame this as refusing to meet Google halfway. People have tried to come up with solutions that would meet the usecases that Google want to deal with and which don't end up forcing people to tie their kernel to their userland. Nokia achieve comparable power consumption without any of the wakelock infrastructure, so it's clearly not a requirement in order to hit these targets. What would you expect a meeting halfway solution to look like?

        • Re:Technical aspects (Score:5, Interesting)

          by Anonymous Coward on Thursday February 04, 2010 @05:29AM (#31020144)

          I'm commenting anonymously because I'm closely involved with Android. I'm not going to comment on whether wakelocks are good or bad.

          But mjg59's comment about ARM retention state being as good as suspend is blatantly wrong at a SoC level. There are several good reasons why a suspend details is better than retention but I can't go into the details due to NDAs. But I can vouch that I have personally seen power usage shoot up on well known Android phones when suspend is disabled and only retention is done.

          So, mjg59, I would kindly request that you stop making such claims. I doubt you have worked on embedded devices -- I believe you work on server level stuff -- but you most certainly haven't worked extensively on the SoCs being used on Android phones.

          Just to make my stance clear, I'm all for having the Android kernel merged into mainline.

          • Re:Technical aspects (Score:4, Interesting)

            by mjg59 (864833) on Thursday February 04, 2010 @09:46AM (#31021484) Homepage

            Firstly, thanks for posting this. It's the kind of thing that we never really got out of previous discussion on the topic, which makes it much harder to make reasonable technical decisions.

            Secondly, your results are interesting. I'd be fascinated to know whether they're due to the implicit differences between retention and suspend (ie, transitioning to full suspend stops processes that would otherwise be generating wakeups while retention doesn't, or cuts power planes that should otherwise be powered down manually) or because of fundamental silicon level issues. On the other hand, I don't think it fundamentally matters. We have an rtc that's capable of generating wakeup events, so it's acceptable for the lowest level runtime idle state to be system suspend with the rtc set for the next scheduler tick. Just make sure that the latency values are set correctly and it ought to work fine with the existing cpuidle code.

          • Re:Technical aspects (Score:5, Interesting)

            by pslam (97660) on Thursday February 04, 2010 @03:16PM (#31025566) Homepage Journal

            So, mjg59, I would kindly request that you stop making such claims. I doubt you have worked on embedded devices -- I believe you work on server level stuff -- but you most certainly haven't worked extensively on the SoCs being used on Android phones.

            I have worked on embedded devices - Linux based and others - for over a decade, and mjg59 is right. If you need something as brutal as hard suspend mode, you're doing it wrong. Any serious low power optimized ARM SoC can run down to very low current when idle, and has peripherals which can be individually clocked down and/or gated. I did work in a periphery way on the G1 at Google, and was very surprised at the way power gating was done. Put simply: the only other embedded OS in the same class as Android which does power gating like this is Windows Mobile. Everyone else learned it was unnecessary a long time ago. I was fairly shocked how few engineers had ever done serious embedded work before, and the result shows.

            I know the Qualcomm parts have horrendously stupid design decisions in them which prevent decent idle current, but it's a wash compared to the other sources of battery drain. It's also a wash compared to the damage it does to your code design to support full suspend as part of normal per-second operation.

            The Linux maintainers are right: Android is just doing it the wrong way. If there's any one feature I think Android could have done without, it's wake-locks. Learn how to use fine-grained clock switching and gating, not brutally-coarse-grained suspend. This isn't a bloody laptop. And no, I'm not saying this as a back seat driver: I really have done this kind of crap for a decade.

      • Re:Technical aspects (Score:5, Informative)

        by GooberToo (74388) on Wednesday February 03, 2010 @07:36PM (#31016760)

        I love how they blast Google for not being willing to meet halfway, but they're doing exactly the same thing.

        It doesn't appear that's the case. It seems Google coded a bunch stuff without consulting other, more knowledgeable kernel developers. Google then announces what they've done and throw it over the wall. The feedback is the design stinks and is very fragile. They also ask why Google didn't leverage the existing infrastructure which is already working, and which seems to have been in place long before Google started, which addresses their very issue. Nokia via their Linux/OMAP ARM efforts don't seem to have trouble using the existing infrastructure.

        Google responds by saying the existing infrastructure isn't a complete solution for their needs. The kernel guys ask why Google didn't simply update the existing code to address their specific needs rather than add poorly conceived new code/interfaces. Even the Linux/Nokia guys step forward and state the existing infrastructure is plenty useful and powerful and is easily able to address Google's need with only minor changes. Furthermore, the general consensus is that the required changes can be made such that its fully compatible with their userspace applications.

        Google response? Who gives a shit?!?!? We don't need it upstream. Let everyone else fend for themselves. We don't care if it ads bloat and is unusable for anyone else.

        Now the kernel guys are left with unmaintained code, which nobody wants, which exists only to add bloat to the kernel, which benefits nobody but Google. Seems to me, Google doesn't care to meet in the middle and they've made it very clear its Google's way or no way. And as result, Android's kernel is more bloated because of it. Seems like a lose-lose for everybody while highlighting just how huge Google's ego can be.

  • "Embrace & extend"!
  • by thetoadwarrior (1268702) on Wednesday February 03, 2010 @05:48PM (#31015322) Homepage
    I suspect this isn't clear cut and there is more than a little "Google is too big we must hate them now" attitude. The fact is Android is open source and anyone can take their code do what they want with it just as Google can take any other open source code and do what they want with it.

    That's the point of open source code. Claiming something is open and all about freedom and then trying force everyone into doing what you think should be done is neither really free or open.
  • In summary... (Score:3, Informative)

    by rickb928 (945187) on Wednesday February 03, 2010 @06:13PM (#31015700) Homepage Journal

    Google has silently forked the kernel. There is an 'Android' kernel, and the mainline kernel

    Is this the first time this has happened?

    Will it matter?

    Apparently, this is reasonably well understood [theregister.co.uk].

    I, for one, welcome our Android kernel overlords. My phone doesn't need server optimizations.

I don't want to achieve immortality through my work. I want to achieve immortality through not dying. -- Woody Allen

Working...