Re: Debian GNU/Linux on tablet hardware
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.
Reply to: