LWN: Comments on "Greg Kroah-Hartman: Android and the Linux kernel community"

Greg Kroah-Hartman: Android and the Linux kernel community

tbird20d — Mon, 03 Oct 2011 18:02:45 +0000

But lots of embedded developers, me included, think that Android has some nice stuff, that is being blocked from mainline by stubborn-ness, ignorance and pride, rather than any substantive technical issues.

Some clarification on "the Android Kernel"

tchalvak — Fri, 18 Feb 2011 06:00:49 +0000

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

"If Android code was important to the mainline kernel..."

dneary — Thu, 09 Dec 2010 10:37:54 +0000

Replying to a really old comment... don't know if that's good or bad LWN etiquette.

To turn this phrase on its head, one could argue that:

If getting code upstream was important to Android developers:
Then they would expend more effort in accommodating concerns that the kernel developers have raised about the patches

No-one likes to maintain someone else's abandoned code.

I only bring this up now because of a recent announcement which reads like a regression to me: http://source.android.com/source/code-lines.html (that said, it has the advantage of clarifying expectations, which I applaud).

Cheers,
Dave Neary.

The New Era of Big Company forks.

bkuhn — Mon, 08 Feb 2010 15:01:00 +0000

It seems to me we've entered a new era of FLOSS development. Big companies that are otherwise supportive of FLOSS in many situations (i.e., Google), can afford to maintain a public fork for as long as they wish. I've written a blog post about this problem.

Greg Kroah-Hartman: Android and the Linux kernel community

rgmoore — Mon, 08 Feb 2010 07:19:42 +0000

you say that you don't think that forks are bad, but then you say that the linux way of eliminating forks is what has made it better than the *BSDs.
If long-term forks are acceptable, than the *BSDs should be the perfect example to point to as a measure of how they are so successful.

Part of the reason that Linux works well is because it lets people with good ideas go off to develop them for a while but always with the idea that those good ideas will be brought back into mainline if/when they've proven their worth. That freedom to develop radical new ideas is why the ability to fork is so important. The problem that the BSDs have had is that they haven't done as well with the merging back into mainline part. They've allowed their forks to become permanent splits instead of temporary development projects.

See, NOW it makes sense...

mjg59 — Mon, 08 Feb 2010 06:34:56 +0000

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
be implemented using Rafael's runtime suspend work. As long as the dependencies are
expressed (and I admit that doing so is problematic right now), a busy driver can do a
pm_runtime_get() and then a pm_runtime_put() when it's idle again. Letting that information flow
up the tree could then allow the platform code to inhibit entry to the deeper states. TI seem to
do this in a more hacky way by simply using the systemwide busmastering flag, which cpuidle will
then use to limit idle to wfi-type states. It's not elegant, but it works.

The next linux pm summit is planned for Boston in August, which is kind of far away. There's the
collab summit in SF in April which isn't generally a highly technical conference but is co-hosted
with CELF this year. I suspect we could probably sort something out for that, if there's interest,
and it's the kind of thing that the Linux Foundation would probably love to make happen.

Some clarification on "the Android Kernel"

swetland — Mon, 08 Feb 2010 06:04:37 +0000

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.

See, NOW it makes sense...

cdibona — Mon, 08 Feb 2010 05:59:38 +0000

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...

swetland — Mon, 08 Feb 2010 05:56:13 +0000

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...

kragil — Sun, 07 Feb 2010 23:54:57 +0000

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
profits.

Greg Kroah-Hartman: Android and the Linux kernel community

vikrampandita — Sun, 07 Feb 2010 19:10:13 +0000

>However I must say that this has been mostly due to the fact that
>TI in the first place should have been much more active.
>After all _they_ produce OMAP, neither Nokia nor Google.

Agree. There sure was slowness from TI, thats changing now:

* Kevin Hilman works with TI as PM maintainer getting most features
upstream actively

* Things improved since 2008 as k.org statistics show with @ti.com contributions:
v2.6.32..v2.6.33-rc7: 251
v2.6.31..v2.6.32: 218
v2.6.30..v2.6.31: 72
v2.6.29..v2.6.30: 32

TI realizes the value of upstream and has a long way to go,
and the change has begun...

See, NOW it makes sense...

mjg59 — Sun, 07 Feb 2010 19:07:15 +0000

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.

Some clarification on "the Android Kernel"

rahulsundaram — Sun, 07 Feb 2010 11:44:15 +0000

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
doing continuous development in a public maintained branch and this makes
it harder to give early review

Greg Kroah-Hartman: Android and the Linux kernel community

swetland — Sun, 07 Feb 2010 09:17:47 +0000

It took a few years for the omap2/omap3 stuff to actually get to mainline and stabilize. I've been watching that process since we started on Android in 2005. I fully believe we'll get there with other SoC support and perhaps even with some of the generic Android drivers, but it's not going to happen overnight.

See, NOW it makes sense...

swetland — Sun, 07 Feb 2010 09:11:27 +0000

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.

I have no worries.

swetland — Sun, 07 Feb 2010 08:59:11 +0000

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

Some clarification on "the Android Kernel"

swetland — Sun, 07 Feb 2010 08:48:01 +0000

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:
- random bugfixes (these are usually pretty easy to submit upstream)
- generic Android related drivers that are standalone (lowmemorykiller, binder, ashmem, logger, etc): These pieces are used by the Android userspace, but not other kernel drivers.
- generic Android related drivers that add new infrastructure. Wakelocks are pretty much the only significant piece here. They are depended on my peripheral drivers, but that can be conditionalized.
- support for new SoCs (msm7k, msm8k, etc) and boards/devices (G1, myTouch, NexusOne, Droid, etc) - they live under arch/arm/mach-*/... and don't have many special dependencies other than wakelocks (which can be conditionalized)

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

See, NOW it makes sense...

jejb — Fri, 05 Feb 2010 19:43:28 +0000

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...

jejb — Fri, 05 Feb 2010 19:38:26 +0000

> 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.

Greg Kroah-Hartman: Android and the Linux kernel community

suzhe — Fri, 05 Feb 2010 06:56:43 +0000

Something like these?
Android on Ubuntu
Android on Moblin

Fragmentation

andypep — Thu, 04 Feb 2010 20:32:12 +0000

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.

Greg Kroah-Hartman: Android and the Linux kernel community

rahvin — Thu, 04 Feb 2010 20:23:02 +0000

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?

See, NOW it makes sense...

rahvin — Thu, 04 Feb 2010 19:51:49 +0000

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.

Greg Kroah-Hartman: Android and the Linux kernel community

rahvin — Thu, 04 Feb 2010 19:25:44 +0000

I'm glad the Android developer posted. He's conveyed something I didn't realize, that is that Google and their developers believe they are right regardless of what others think. It sounds like this might be a corporate problem in that they truly believe they are right and everyone else is wrong.

I don't think anyone would argue that in some instances it's better to be out of tree than in, but it's the exception, not the rule. Part of getting into mainline is listening to other people when they tell you your code is garbage and your solution is the wrong one and that a better one exists. This is especially true when the other people doing the same kind of development (embedded in this case) tell you that your approach is the wrong one as otherwise you might have an argument that what you propose is an embedded specific exception.

It's an eyeopener to me to see how arrogant the Google developers are about their code. It explains their toss it over the wall attitude precisely. I have to wonder how long Google will be able to maintain this attitude with all the other players in the Open Handset Alliance, and most particularly what will happen when Google gets tired of Android and abandons it. It's unfortunate this attitude exists, while the corporation is interested in Android it will raise their costs significantly and when they abandon it if others haven't forked the code it will die. Rather unfortunate, but as I said, it's probably a corporate problem that in the long term will see most Google code abandoned, rather unfortunate but I guess that's what happens when you can't play with others or take constructive criticism. There is an interesting sociological question on where such corporate attitudes develop and whether they are related to some demographic figure, such as average age, of the Google developers plays a role.

Kernel API churn is a good thing

prl — Thu, 04 Feb 2010 18:18:27 +0000

Really.

The Linux kernel occasionally does need to have a subsystem ripped out and re-implemented properly when an API is just plan WRONG (e.g. the Big Kernel Lock). And sometimes it becomes clear that a new API is needed (e.g. multiple linked list implementations reduced to one).

When an API change happens, every single use can be identified and ported. There'll be a transition phase and then the old API will be retired. Admittedly, in the case of the BKL, the transition phase is taking a decade or so, but its removal is undoubtedly a good thing.

There's no build up of crud. Yes, it makes out-of-tree maintenance harder; all the more reason to get ones code merged. And yes, it goes back to Linus and it's one of the best decisions about the development process that he ever made.

Sorry to hear you had a problem with picky hardware, but a regression like this is nothing at all to do with the kernel API.

Greg Kroah-Hartman: Android and the Linux kernel community

rich0 — Thu, 04 Feb 2010 15:34:46 +0000

Forks aren't always great, but I honestly don't think of forks as being a bad thing and I've tried to instill in Google the same ethic.

The big problem with this sort of approach is that projects on the scale of something like Chrome or Android can turn into entities unto themselves with almost no connection to the projects they were derived from.

The last time I downloaded the chromium source the tarball was around 0.5GB - almost all of it from forked dependencies. The resulting build is unnecessarily long, and it ends up losing any benefit from upstream improvements in any of those dependencies. If zlib or whatever fixes a security flaw I need to download and rebuild another 0.5GB tarball to incorporate the fix.

A company the size of Google can sustain this, I guess, but it makes the resulting project unwieldy. There may not ever be a community-based version of chromium as a result, just as there is no practical community- based version of android out there now (I'd define community-based as a fork with no corporate sponsorship). On the other hand, that need-not remain the situation permanently, and there are signs that Google has been trying to integrate with upstream/etc (but they've dug themselves into a bit of a hole).

Sure, forks aren't always a bad thing, but they can be counterproductive and they can lead to isolation. When there is no reason to persist with a fork it behooves us all to work together if we truly value the open source spirit.

I'm worried.

mgross — Thu, 04 Feb 2010 15:02:33 +0000

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)

Greg Kroah-Hartman: Android and the Linux kernel community

nevets — Thu, 04 Feb 2010 14:44:59 +0000

I am one of the RT developers and even maintained the RT tree for a while in the past.

When we first started working on -rt, it was not too different from Android. That is, we were working in a niche market. We did not even know that mainline needed anything we were doing. At the time it was more R&D.

Maintaining a tree outside of mainline is extremely difficult. As -rt developed, we realized that it has advantages for mainline. But more importantly for us, the more we got into mainline the easier our job would be.

Mainline was a mess with respect to Real-Time. We started sending in patches to clean it up. We started combining more spin_lock() and local_irq_disable() into spin_lock_irq() which helped mainline annotate what locks were being used in interrupt context and which were not.

hrtimers, generic timers, generic interrupts, lockdep, ftrace, mutex, pi futex, and a list of others all came from this -rt work.

Once we realized that -rt was worth the effort, we started working hard to get all of it into mainline. If we just passed the patch over to the mainline developers and said, here it is, take it or leave it, they would have laughed in our faces. Ever single enhancement that we had in -rt, we had to rewrite 2 or 3 times before it was acceptable for mainline.

Having your code in mainline will make things much easier in the long run. Believe me, it can be hell to constantly keep up with mainline. If you look at your work and ask yourself, how could this help everyone not just our little niche, you will see better solutions that will not only help mainline, but will also help you. Every time we did a rewrite, the end result was always something better for the RT tree.

Listen to the mainline developers, they may actually make your product better.

See, NOW it makes sense...

mjg59 — Thu, 04 Feb 2010 14:16:53 +0000

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...

gregkh — Thu, 04 Feb 2010 14:12:27 +0000

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.

Greg Kroah-Hartman: Android and the Linux kernel community

daniels — Thu, 04 Feb 2010 11:48:09 +0000

Sure, there are quite a few ARM/SoC forks, and there are a lot of very unhappy users facing a lot of problems that will probably never be solved, or will be solved with extensive backporting.

There are also (and check linux-arm if you don't believe me) a lot of SoCs that work flawlessly, out of the box, with stock kernels. The OMAP series is used quite extensively, and the linux-omap tree is very active and frequently merged back into the mainline; I believe that linux-2.6 works out of the box on the N900, with no particular disadvantage, and certainly no regressions in power management.

Greg Kroah-Hartman: Android and the Linux kernel community

broonie — Thu, 04 Feb 2010 11:39:50 +0000

Not really - it's a culture thing, originating from the chip vendors in the most part.

The overwhelming majority of the problem ARM faces is that most of the CPU vendors have traditionally seen Linux as a traditional embedded OS that you produce a BSP for with your own custom stuff in it and don't contribute to. This means that the core code required to boot the processor from one of these systems is non-mainline, and few of the companies building products have the time or resource to mainline it. The end result is that you end up with communities coalescing around the vendor BSPs which are often based on old kernels which make it difficult to share anything with mainline.

This is getting a lot better these days - many of the major SoC vendors are contributing their ports upstream.

See, NOW it makes sense...

kragil — Thu, 04 Feb 2010 11:36:52 +0000

That answer just gave me an idea:

How about giving contributors not employed by Google or Open Handset members
a free Google phone once they have a certain number of patches in the
Android stack.

It is easy to do (just grep some SCM output, or just put "providing proof"
burden on the applicants) and the number of patches needed can be set so
that certain budget limits are not exceeded.

Kernel hackers would certainly be ledgeable and if they bother to apply for
a phone they might actually contribute patches.

Disclaimer: I certainly wouldn't qualify.

See, NOW it makes sense...

SimonKagstrom — Thu, 04 Feb 2010 11:35:35 +0000

The Samsung Spica Android phone is also built on their own platform (6410 I
believe).

See, NOW it makes sense...

broonie — Thu, 04 Feb 2010 11:24:34 +0000

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.

Greg Kroah-Hartman: Android and the Linux kernel community

istoppa — Thu, 04 Feb 2010 10:51:16 +0000

Getting power management working decently on N900 has not been an easy task and trying to do it in a way that would be acceptable upstream has not made it easier.

However I must say that this has been mostly due to the fact that TI in the first place should have been much more active.
After all _they_ produce OMAP, neither Nokia nor Google.

And it gets even more difficult to prove to upper management that going with the community is the right way, when a competitor comes out quickly by leveraging code that has taken time and money to get accepted.

I think the fact that the Android code has been kicked out finally proves the need to play by the rules also for big companies and that even if some bending backward might be needed in order to deliver products, eventually the open source activity cannot be omitted or indefinitely postponed.

Btw, usually interacting with the community also gives significant advantage in terms of getting advice from highly skilled people on how to deliver a better product, so it should rather be sought after, not avoided.

Said this, I have perceived the lack of better participation from Android as a big loss, since it would have been much more productive for all the sides to have open dialog and confrontation about something that, after all, should be taken as granted (good use time) and not become a differentiating feature (we already have userspace eyecandies for that).

Greg Kroah-Hartman: Android and the Linux kernel community

mfuzzey — Thu, 04 Feb 2010 09:08:45 +0000

>in the x86 world, imagine that every motherboard was a separate architecture, with devices at different addresses and supporting different features.
I work a bit on ARM and I think the problem is somewhat exagerated.
Sure it is complicated compared to x86 but without a common hardware architecture (which I don't see ever coming for embedded devices) its not likely to improve much.

>the proliferation of ARM sub architectures is a major problem.
You don't have a seperate architecture per board but per SoC (or more frequently per SoC family) - for example Freescale iMX21 and iMX27 are very similar and share most of the code.

If your SoC is already supported you only actually have to write one board specific C file, which is basically a set of platform data tables mapping memory addresses, IRQs etc. If the device tree stuff gets merged it will be even easier though not IMHO fundementally different.

>in the embedded space, everyone starts off with the idea that the product is a one-off, but linux has now been used long enough that companies are starting to come out with 2nd and 3rd generation products, which take the same basic design, update to current chips, and add new features.
Yes and that is exactly the reason why following mainline and getting your stuff merged is a good idea.

If you're doing a one shot project with a short lifecycle it may not matter but if you either
a) Support your product for a long time (10+ years in my company's case)
b) Plan on releasing new versions on the same basic design
It gets much easier if you can just rebase to the latest code for each version.

One problem is that the kernel patch submission and review timing may be incompatible with your product release cycle. But that just means that you keep the patches in your local tree while waiting for them to be accepted upstream. This way your local patch stack should diminish over time.

Greg Kroah-Hartman: Android and the Linux kernel community

cdibona — Thu, 04 Feb 2010 07:38:40 +0000

And again. And again. And again, for many years to come.

Greg Kroah-Hartman: Android and the Linux kernel community

cdibona — Thu, 04 Feb 2010 07:37:04 +0000

Well, if anything, I was probably unfair to the BSDs, there are some solid , incredibly useful forks of bsd.... OpenBSD comes to mind (but that's gonna start a centithread if I bring that up too much) as does FreeBSD. They're both healthy and have solid direction.

I also happen to think that if you look back on this a few years or four from now, this will all wash out. By 2.8 maybe? :-)

See, NOW it makes sense...

cdibona — Thu, 04 Feb 2010 07:33:16 +0000

A combination. It's always a mix, from what I understand.

LWN: Comments on "Greg Kroah-Hartman: Android and the Linux kernel community"

Greg Kroah-Hartman: Android and the Linux kernel community

Some clarification on "the Android Kernel"

"If Android code was important to the mainline kernel..."

The New Era of Big Company forks.

Greg Kroah-Hartman: Android and the Linux kernel community

See, NOW it makes sense...

Some clarification on "the Android Kernel"

See, NOW it makes sense...

See, NOW it makes sense...

See, NOW it makes sense...

Greg Kroah-Hartman: Android and the Linux kernel community

See, NOW it makes sense...

Some clarification on "the Android Kernel"

Greg Kroah-Hartman: Android and the Linux kernel community

See, NOW it makes sense...

I have no worries.

Some clarification on "the Android Kernel"

See, NOW it makes sense...

See, NOW it makes sense...

Greg Kroah-Hartman: Android and the Linux kernel community

Fragmentation

Greg Kroah-Hartman: Android and the Linux kernel community

See, NOW it makes sense...

Greg Kroah-Hartman: Android and the Linux kernel community

Kernel API churn is a *good* thing

Greg Kroah-Hartman: Android and the Linux kernel community

I'm worried.

Greg Kroah-Hartman: Android and the Linux kernel community

See, NOW it makes sense...

See, NOW it makes sense...

Greg Kroah-Hartman: Android and the Linux kernel community

Greg Kroah-Hartman: Android and the Linux kernel community

See, NOW it makes sense...

See, NOW it makes sense...

See, NOW it makes sense...

Greg Kroah-Hartman: Android and the Linux kernel community

Greg Kroah-Hartman: Android and the Linux kernel community

Greg Kroah-Hartman: Android and the Linux kernel community

Greg Kroah-Hartman: Android and the Linux kernel community

See, NOW it makes sense...

Kernel API churn is a good thing