Building a booting kernel for Android using their own code still eludes me. I guess it would help if I knew anything at all about the ARM platform, as I have no idea what I am doing. Still, the code dump fails the “anyone should be able to build it” test rather strongly, judging from posts on the android mailing lists.
Build problems aside, the more egregious failure of the Android open source project is the lack of the “upstream first” mentality. Most Linux software providers follow this strategy to a large extent, which is simply: any patch that goes in my distribution should go to the mainline kernel first. The benefits are obvious: no need to maintain a fork forever, and everyone gets the goods as soon as possible. Even if the patch only serves the developer’s own interests, upstreaming it often has the benefit of vetting the interfaces and producing more universal APIs (the wakelocks discussion that followed the code dump is an example of this done backwards).
Google, however, sadly took the other road: get the product out the door, then worry about pushing bits upstream when we get a chance. The problem is “when we get a chance” never, ever happens, and there’s no motivation to push changes upstream when your product has shipped and it’s now forever in deep maintenance mode. That job of upstreaming is left to the community.
So far there’s no real indication (apart from the userland stuff) that you actually can build the G1 kernel and userland from the code dump. Google engineers are unclear whether everything on the phone is in the codebase (clearly some proprietary bits are not). Meanwhile they have their own fork of qemu, their own fork of the kernel, their own fork of webkit, and so on.
I suppose we should not fault Google too hard: after all, some code is better than no code at all. And if they want to maintain forks of .* forever, that is clearly their prerogative. However, had they worked more closely with the community at the start, the Android platform would be stronger today. They might already have a decent wireless driver, for example.
We’re trying. We can’t delay ship until after everything makes it upstream though. At the end of the day we need a tested and qualified userspace and kernel build that OEMs can actually ship on top of. I’d love to see us converge more with the mainline kernel, because it’s waaaay easier to not have to be rebasing and shuffling our patches forward to follow the mainline. The process is pretty slow going at times, and I’ve set it aside on multiple occasions when the effort to get things reviewed and moving forward started consuming time needed to actually ensure products could ship.
Arve’s been wrangling with the linux-pm list for months now on the base power framework, etc, which other stuff depends on, for example. So for good or ill, it’s not entirely for lack of trying…
– Brian
Thank you for your perspective, and I do appreciate yours and Arve’s efforts in continuing to work towards upstreaming the core code (yes, an often thankless and frustrating task, unfortunately). In that respect, I’ll happily admit my original post was wrong as far as Google is concerned; there is still an ongoing effort to get that code in the mainline after the initial ship date. For many other vendors, whose drivers magically appear on a website one day, “built on any kernel once” seems to be the goal.
Ship dates and mainlining code are going to be in tension, for sure, as are other business concerns like competitive advantage. Except for the latter, publishing code early is almost as good as mainlining it early — at least then issues get on the appropriate peoples’ radar (e.g. next person who rewrites PM might remember that company X wants feature Y, oh and they already have a patch.. guess whose interface is the template).
“Upstream first,” primarily a yardstick by which distributions are measured, is perhaps an unfair one to be applied across the board, and those companies who are good at working within the community still struggle in some cases (cf intel wireless). But it’s a nice target to aim for, and Google could be a leader here.
A few months on and things are looking a bit better: HTC is shipping binary releases that more closely match the code drop, the community has by and large figured out how to build and in some cases enhance the released code, and people are still arguing about how the OOM notifier should work. It just seems like we could have been here six months ago.