W dniu 28.10.2011 17:46, Jeremiah Foster pisze:
Android's Linux kernels are supported (maintained?) by Linaro.
With my Linaro hat on I must object. Depending on what you meant the statement above is either highly inaccurate or simply untrue.
Hence the question mark. :)
I think what I originally meant is that we don't focus solely on Android.
"Improved" is the word I would use, that implies neither support nor maintenance as we are between the vendors (that are also part of Linaro) and upstream kernel community (that we are a part of) and we have no control of either side and their actions. As to what we do check our FAQ (http://www.linaro.org/faqs/) and read on.
Android kernel situation is complicated and varies per board/SoC. What Linaro does is try to upstream and unify the kernel for Linaro member companies SoCs.
What does that mean in practice?
Disclaimer: I'm not a kernel developer. I have experience in the non-Intel part of the world but I'm not the sort of person with up-to-date hands-on experience. For those folks please look at traffic in linaro-dev@lists.linaro.org and at our patchwork instance at patches.linaro.org. You can see what kind of patches we push upstream and if they have landed yet.
As for your question, read on.
A lot of ARM devices have a BSP kernel (android or not) that is prepared by some 3rd party (sometimes also by the vendor themselves if the device is a clone of the reference design) and that kernel is generally not pushed upstream.
This affects, by far, the vast majority of devices out there (I'd say that nothing gets pushed by those companies simply because their work mode does not require such a step - we are working on educating them in the benefits of working both towards products and common code base).
The ARM tree in the upstream kernel is, again, by far, the largest of all the other architectures. If I remember correctly it is in fact larger than *all* the other trees combined. The reasons for this are complicated but can be generally simplified to code duplication between the different devices and greater diversity in the actual hardware as compared to other platforms.
To get ARM Linux healthy we need to reduce that clutter and make sure that support for the latest and greatest hardware is upstream quickly and the code is being actively maintained by everyone.
This is far from finished and uniform. The "BSP" kernel that hardware vendors provide is not supported by Linaro and in fact often contains code that cannot go upstream.
What does it use this proprietary code for? To know the APIs or to get other hardware interface info? Isn't that a little risky? Won't proprietary, and potentially patented IP leak into the Linaro work? (Not that I believe in IP.)
The term proprietary is a bit misleading, the code IS released as GPL. It is simply there to support some parts (often userspace or "firmware") that is not open sourced and cannot be for all practical considerations.
As for the patches in general, there are different reasons why they are not suitable for being proposed and included upstream:
1) Shabby code, against old trees, copy-pasted from another similar device, maintenance hell. This is, by my unqualified judgment, the vast majority of the problem.
2) Code that has no good place in the kernel just yet because the kernel interfaces are insufficient for the extremely complicated world of ARM SoCs. Off the top of my, unqualified, head: power management, memory management, everything related to graphics and probably many more. Here the reason for not being upstream is that there is no consensus on how to do something (how to support a certain class of SoC components) that could be applied to many vendors and non-arm world as well. Here the people that write the BSP cannot solve the problem and just implement their own solution to meet the deadline. Such code is often very good but there are many similar solutions that are quite nontrivial to merge into one sensible codebase. One such example is memory management where we have no less than 3 or 4 competing interfaces from various companies and there is a working group inside Linaro and the greater Linux community that tries to solve this problem.
3) Bits that enable proprietary userspace drivers. The reasons are obvious. This could be related to lots of different things, not only graphics as people often think. IP and software edge (optimizations that make otherwise identical hardware perform better than competition) is probably a big motivation here. The IP protection is not only used as in "don't steal our stuff" but rather "hey, with this being binary it is harder to prove that we violate a specific patent you have". In retrospective this is a thing those companies obviously need. Just look at how many Android handset vendors pay to, for example, Microsoft, for patents that allegedly apply there. The world of graphics is riddled with patents and I'm sure that a big money-laden hardware vendor is a good target for whoever owns the patents.
Linaro has several trees, including a grand unification tree that tries to support all the member companies chips in one tree (and one binary, thanks to device trees) but this effort is years away (my personal estimate, I don't speak for the organization). In addition we have several trees for normal/androidized kernel for each board. In the latest 2011.10 release hardware was not supported in 100% on any board that I'm aware of.
Having said that the term "supported" seems inappropriate to me. We do work on those boards though.
How would you define it?
By "work" I meant "we are *working* on making the kernel and userspace on those boards better in each release". Better is shared amongst:
1) More patches landed upstream, thus less delta. 2) Less duplication within the kernel (better code), more device tree usage, closer to having one kernel binary that supports several different boards. 3) Better power management, stability, performance, more features, bells and whistles. 4) Less delta from the android variant to the normal variant. More discussion and more consensus on how to join the two worlds.
And let's not forget, my own personal favorite, more validation. The code is tested both manually and automatically and the scope, coverage and quality is pushed forward each time.
Anything that runs Android can run GNU/Linux.
This is a gross oversimplification IMHO. You usually get androidized BSP kernel from a few months/years ago with binary parts that have no corresponding source code. Good luck booting vanilla kernel there.
But it appears to me that all the official boards that are targets for Linaro can run a vanilla kernel, is that not the case? If not, what BSP stuff are you referring to - graphics acceleration?
No I don't think that is the case. A quick glance at http://git.linaro.org/gitweb will show you how many trees we have. Except for the explicit upstream trees that Nico maintains none of the important changes in other trees are upstream today (at least not yet).
Even the Linaro various kernels (which are _not_ the BSP kernels) fail to work sensibly on all of the boards today. Next-gen boards are usually the ones with weakest support (although that is rapidly changing, thanks to what we are doing). Often most primitive board features work (like, it kind of boots with a specific boot loader and the CPU runs) but anything you definitely want those boards to do: power management, stability, sound, graphics, 3D & multimedia, wifi/bluetooth, FM radio, GPS(?), DSP suppoet, ARMv7 optimizations, is simply not there.
Best regards ZK
PS: I think that you should ask those questions on @linaro-dev. I could be talking nonsense here and the people that really know simply did not see this message. Therefore I'm cross-posting to linaro-dev.
On Fri, Oct 28, 2011 at 5:59 PM, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Disclaimer: I'm not a kernel developer. I have experience in the non-Intel part of the world but I'm not the sort of person with up-to-date hands-on experience. For those folks please look at traffic in linaro-dev@lists.linaro.org and at our patchwork instance at patches.linaro.org. You can see what kind of patches we push upstream and if they have landed yet.
ok - this is potentially misleading, zygmunt, at best irrelevant. ok, shall i point out a correction, and you, or someone else from linaro, can, if it is incorrect, provide the required corrections, yes?
by mentioning the above patch queue (on the debian-arm list), then *despite* previously mentioning that linaro is "between the vendors and the kernel developers", there is a risk that people could not connect the dots between this and the previous paragraph (seen that happen so many times it's unreal) and thus it would appear - to them - that linaro is *still* seen to quotes be an authority unquotes regarding patches [for specific hardware]. the correction - if any is needed - is that linaro is NOT an "authority" of ANY KIND regarding "definitive patchsets" or in fact an authority of any kind PERIOD.
linaro is, in fact an "accelerator", helping SoC vendors to push "lowest common denominator" code into the linux kernel for the convenience of *MULTIPLE* hardware and software developers using that PARTICULAR SoC, but linaro are not, repeat NOT "direct" suppliers of linux kernel source code for a specific device.
perhaps if any code for a particular device _is_ pushed upstream by linaro, it is almost "by accident", by nature of it, for example, being a particular example "BSP" or convenient "Reference Platform".
putting it into context: linaro is paid by _SoC Vendors_. linaro is *not* paid by individual Hardware Factories (afaik) to do hardware-specific, device-specific linux kernel development.
thus in that context, whilst it is nice that linaro is doing upstream patches, and it's nice that you mentioned it, it is in the context of this discussion, "off-topic".
would that be a correct assessment?
i apologise a) if it is not - please do correct things b) for feeling obligated to point out that linaro's patches and patch development is "off-topic".
l.
W dniu 28.10.2011 20:10, Luke Kenneth Casson Leighton pisze:
On Fri, Oct 28, 2011 at 5:59 PM, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Disclaimer: I'm not a kernel developer. I have experience in the non-Intel part of the world but I'm not the sort of person with up-to-date hands-on experience. For those folks please look at traffic in linaro-dev@lists.linaro.org and at our patchwork instance at patches.linaro.org. You can see what kind of patches we push upstream and if they have landed yet.
ok - this is potentially misleading, zygmunt, at best irrelevant. ok, shall i point out a correction, and you, or someone else from linaro, can, if it is incorrect, provide the required corrections, yes?
I was just trying to state my opinion that Linaro "supporting android kernels" is kind of misleading in its own way. While I'm not a kernel developer I'm deep in Linaro and I try to stay informed about what is going on. I would love to see responses from other Linaro engineers as that would correct my personal opinion if I got something wrong.
Note: if the discussion below is off-topic to the original thread please feel free to ignore me.
by mentioning the above patch queue (on the debian-arm list), then *despite* previously mentioning that linaro is "between the vendors and the kernel developers", there is a risk that people could not connect the dots between this and the previous paragraph (seen that happen so many times it's unreal) and thus it would appear - to them - that linaro is *still* seen to quotes be an authority unquotes regarding patches [for specific hardware]. the correction - if any is needed - is that linaro is NOT an "authority" of ANY KIND regarding "definitive patchsets" or in fact an authority of any kind PERIOD.
Linaro is more than a random collection of kernel hackers. The key advantage "we" have is that those hackers come from hardware vendors directly (and here I mean the people that actually design the SoC and then produce chips you can buy). Linaro is in a special position as it can attempt cross-vendor solutions on a scale nobody has attempted before. That is much stronger than any other group that I know of. We can, in a way, discuss and implement de-facto standards that the main ARM vendors will use in BSPs for subsequent products.
linaro is, in fact an "accelerator", helping SoC vendors to push "lowest common denominator" code into the linux kernel for the
Yes, Linaro is an accelerator. I would not, however, limit us to the lowest common denominator. We are working on solving the big problems that ARM kernel faces. That affects and involves everyone but is not equivalent to lowest common denominator in my opinion.
convenience of *MULTIPLE* hardware and software developers using that PARTICULAR SoC, but linaro are not, repeat NOT "direct" suppliers of linux kernel source code for a specific device.
No, that is not our goal (to be the supplier of kernel trees for random hardware). What you may find interesting however is that some hardware device manufactures (not SoCs vendors) want to use or sometimes even _require_ Linaro-based trees for their devices.
I think that is a fantastic validation of our efforts. Working with Linaro trees is faster and thus cheaper for those vendors.
perhaps if any code for a particular device _is_ pushed upstream by linaro, it is almost "by accident", by nature of it, for example, being a particular example "BSP" or convenient "Reference Platform".
Not by accident and not for a particular device. Our intention is to support the _next_ set of SoCs in the upstream kernel. When a company goes out to search for devices to build their next product those SoC will be already enabled and not only in a random BSP package but straight in the upstream vanilla kernel.
putting it into context: linaro is paid by _SoC Vendors_. linaro is *not* paid by individual Hardware Factories (afaik) to do hardware-specific, device-specific linux kernel development.
Some of the device vendors are coming closer to Linaro. I can cite one example from memory, Genesi, the manufacturer of several interesting freescale based products has joined Linaro to improve cooperation between their engineers working on next Genesi products and Linaro's common vision on how things should work.
thus in that context, whilst it is nice that linaro is doing upstream patches, and it's nice that you mentioned it, it is in the context of this discussion, "off-topic".
As stated at the beginning of this message I was attempting to correct an inaccurate, in my opinion, assessment of what Linaro is doing.
In a finishing note I'd like to state that the devices that we work on daily (and improve GNU/Linux experience on) are being used to form products we'll see on the market.
Initially "development boards" were a queer concept for the SoC vendors but I think that is rapidly changing and more vendors start to see the effect making those devices available on the market has on their ecosystem. Devices are turned into prototypes and products, more smaller-scale companies can participate, more code is written in the community to support those boards. The ecosystem grows faster.
I can point to a simple recent example: the ST-E snowball board is actually a full-featured product platform that can be taken from a "prototype" to "product" without complex hardware redesign. This means that one wishing to obtain a supply of hardware for a free ARM PC like product will find that there are many virtually identical (and well supported by free software) devices on the market. I think that is a good thing.
Best regards Zygmunt
On Fri, Oct 28, 2011 at 09:30:19PM +0200, Zygmunt Krynicki wrote:
I was just trying to state my opinion that Linaro "supporting android kernels" is kind of misleading in its own way. While I'm not a kernel developer I'm deep in Linaro and I try to stay informed about what is going on. I would love to see responses from other Linaro engineers as that would correct my personal opinion if I got something wrong.
If the context in this message hadn't been butchered (and the message itself wasn't the size of the Britannica) I would risk a more complete answer; however, generally Linaro a) does intend its kernel releases and distribution images to be runnable and useful to developers using our members' development boards and b) we do significant work testing, fixing and maintaining said kernel releases and distribution images.
If that wasn't the question, can somebody restate it clearly?
-
Christian Robottom Reis -
Luke Kenneth Casson Leighton -
Zygmunt Krynicki