[Arm-netbook] Ask him for Android DDK (Was: I Have An Possible Chance To Meet An ARM Senior Manager)

[luke.leighton]

On Sun, Oct 7, 2012 at 10:55 AM, Alexey Eromenko <al4321 at gmail.com> wrote:
>>If I meet him would you have any thing you would like me to talk about?
>
> If you could ask him to help Google design a kernel space framework
> (DDK, driver development kit) for Android.

 alexey - there's so much here, it's hard to digest all at once, but
my general feeling is one of unease at what you're proposing, because
i don't believe it goes deep enough to the root of the problem.
fortunately, i believe that there's a way that EOMA-68 will help solve
the *underlying* problem.

 the key is that the underlying kernel on which the android userspace
OS operates is Linux.  therefore, what you're asking is **NOT** that
Google should help **ANDROID** to create a DDK, but that you're asking
that Google should help **THE LINUX KERNEL** to create a DDK.

 unfortunately as we've seen, there was a big row recently where
miguel de icaza pointed out some things where people are blurring the
distinction between "an OS" and "its kernel" and are taking their lead
from Linus Torvalds on *desktop* decision-making.  Linus rejected this
vehemently, of course, citing that they of course create stable APIs
but that the linux kernel developers effectively reserve the right to
make fundamental architecture changes at will.

 ... and that's the problem faced by trying to create a stable DDK, right there.

so effectively what i'm saying is that Android faces *exactly* the
same proliferation problems that *all* GNU/Linux OSes face, which is
that each hardware device has to have its Linux kernel hard-customised
*specifically* for that hardware, when the Linux kernel is continously
undergoing drastic revision.

devicetree is "supposed" to help solve this hardware-customisation
problem... but it simply comes nowhere near close enough.  devicetree
simply moves the problem out of the linux kernel and into devicetree
specifications.

by contrast: if you had a hardware standard (EOMA-68) that was simple
and comprised of other proven stable decade-old I/O specifications,
the job of adding a new SoC is made drastically simpler: you merely
have to write linux kernel code that conforms to that standard.. and
AUTOMATICALLY YOU GET ACCESS TO THE PRE-WRITTEN DEVICE DRIVERS FOR
PRODUCTS THAT CONFORM TO THAT EXACT SAME STANDARD.

do you see how that solves the exact same problem, just in a different
way?  each new SoC that comes out, a DDK doesn't have to be customised
solely and exclusively for each and every single piece of hardware in
existence into which that SoC is ever going to go.

> Android is quickly becoming a full-blown O.S, a desktop replacement,
> and it needs more low-level abilities to go way beyond one-trick-pony
> apps.

 in other words, it has to have added back into it exactly the POSIX
standards (or other standards) that were removed from it in the first
place.

 android was never designed to be a full-blown OS.  it was never
designed to be a desktop replacement.  it has a completely different
mindset behind it.  they truly expect the devices to be throw-away
"toys".  "so a device doesn't do what you want? so what!  get another
one that does!" i feel is the general attitude, here.

i think, therefore, that efforts would be better spent running Android
as a Virtual OS within kvm or other Virtual Machine, on CPUs that have
virtual machine support (ARM Cortex A9 and above).


> Today Android has SDK (Java) and NDK,

 this doesn't inspire me with any confidence of *any* kind.  it's hard
to explain, but it's to do with java itself rather than anything else.

> I would like to hear some comments on Wish #37260.
>
> http://code.google.com/p/android/issues/detail?id=37260

 ok - this is effectively solved by merely upgrading the entire
firmware or by replacing the whole kernel with one that contains all
the necessary modules.

 the problem there is that the vendors of the device FAIL to honour or
in many cases to even comprehend the GPL Software License.

 in other words: even if you got google to "solve" this problem by
allowing kernel modules to be installed, the massive and endemic GPL
violations problem makes it completely and utterly pointless to even
*have* the ability to dynamically load kernel modules.

 do you see?

 so again, here, EOMA-68 helps out, because of the standardisation.
even in cases where there were GPL violations of EOMA-68 CPU Cards,
the task of reverse-engineering the linux kernel onto that hardware
would be enormously simplified, because the only part that would need
to actually be reverse-engineered would be the CPU Card part, *not*
the I/O side (for the products that the CPU Cards go into).

 you get the point i'm making, here?

> Some Android developers disagree that there must be a way for kernel
> modules to exist on Android, citing security issues, but the upside of
> kernel modules is a *HUGE* one, just like going from HTML-only-apps to
> native apps.

 you have to solve the GPL violations problem first.  otherwise you
can't get hold of the right kernel source code headers, or the
toolchain, and you can't even *begin* to compile up a dynamic module.
and, because of the "right of the linux kernel developers to do
whatever they want", you *have* to have the exact same toolchain and
you *HAVE* to have the exact same GPL kernel source code.

> 2. Frozen kernel API/ABI
> ======================
> In the upstream Linux Kernel API/ABI stability is non-existent (for
> internal interfaces).
>
> Solution: Debian-like frozen kernels, changes once per few years.

 this is not going to happen.  that's just a realistic assessment.
Android is completely out-of-control, with multiple SoC designers
whose first language isn't English taking GPL Linux kernel source code
and creating binary-only OSes *without* giving even the ODMs and
certainly not giving the Factories access to the source code.

 this is an impossible situation on which to try to place any kind of
organisational structure at the software-only level.

 which is why i'm advocating doing it at the hardware level, giving
everyone a financial incentive to work together due to cost savings
and simplification of the software development *around* the hardware
standard, EOMA-68.

> NOTE: To achieve compatibility of installing kernel modules, there
> must be a standard compiler tool-chain for Android, also frozen (i.e.
> non-changing for few years, like in Debian).

 yes.  again - this simply isn't going to happen, because the
tool-chain itself needs to be customised so closely to the hardware.
what are you going to standardise on?  armel? armhf? arm-next-version?
 arm-optimised-for-Cortex-A7, which has a completely different
pipeline layout from Cortex A15?

 no - it's literally impossible, and not even desirable, to have a
"standard" compiler tool-chain for android.  the worst thing that
would happen would be that the toolchain has to cater for "Lowest
Common Denominator" - a bit like forcing everyone to use gcc optimised
for intel 386 and ignoring all the SSE, MMX and other features for x86
CPUs that are 2 decades more advanced than the 386.

 by contrast: if you had an EOMA-68 hardware standard where the CPU
Card came pre-installed with the OS, the kernel could be optimised for
that CPU, yet the CPU Card would have access to a wide range of device
drivers so vendors would be forced to clean up their act.


 so, to summarise:

 * you're proposing that android allows binary-level modules to be
loaded (a la udev and a la "modprobe") even 3rd party ones.
 * BUT, this is an impossible situation to solve, because you have to
solve the endemic 98% GPL violations problem by SoC vendors, ODMs and
retail outlets, first, as well as a whole host of other problems.
 * EOMA-68 by contrast helps to solve the exact same problem, by
"normalising" and "stabilising" product development on both sides of
the EOMA-68 fence: the amount of linux kernel porting needed to be
done by each type of team is drastically reduced.

it's not quite as clear-cut as that, but it's about the gist of it.

did i miss anything?

l.