[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 1:53 PM, Gordan Bobic <gordan at bobich.net> wrote:
> Note: Off-list because I didn't want to scare off any potential hardware
> manufacturers that may be reading the list. Please censor as you see fit,
> but feel free to post to the list any edited version.

 thanks for your concern, gordan, but because of the risk of things
appearing to be a "ClimateGate" i much prefer things to be discussed
in the open, warts n all :)  i _like_ being told "you're wrong!
here's a better way!".

 anyway, let me forward the original, then reply to it separately, ok?

On 10/07/2012 12:43 PM, luke.leighton wrote:

    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.


A couple of points here. If you are referring here to source-level
customizations, then this is down to the hardware and SoC vendors not
caring about whether the hardware is supported in mainline, and
rampantly violating GPL by not releasing their sources.

I would _LOVE_ to see this change, but I don't realistically see that
happening without a major world-wide litigation that would set a
precedent of GPL being enforceable and make an example of both the
companies that are responsible for the GPL violations and the
directors of those companies with both large fines and directorship
bans for wilful licence infringement on large scale.

In the western world I can almost see it happening against the likes
of StorageOptions and similar small-scale producers, but against
thousands of small-scale here-one-week-gone-the-next companies in the
far east that are long gone by the time a 100,000 of their devices hit
the shelves in Europe? I'd say that's wishful thinking at best. It
would require all sorts of unworkable responsibility shifting toward
the end retailer, which would likely only further accelerate driving
the few remaining retailers out of business all together.

I don't really know what the realistic solution to the problem is.

If, OTOH, you are talking about the issue of one binary kernel booting
on multiple ARM devices, I believe that is already almost ready in
kernel 3.7. There was something about this on /. a few days ago, IIRC.


    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.


Maybe. But the problem still remains on a lower level in the sense
that a lot of SoCs take ages to get proper kernel level support for
all of their built in features, even before we start talking about
implementations and choice of components and protocols for connecting
to all the various external add-ons.

EOMA68 has a LOT of advantages in terms of standardizing things, but
the it also increases the cost of the end device if you have the
resources to implement the device from scratch and plan on selling
tens of thousands of them. Ultimately, the cost of the PCMCIA
connector and casing is something you can lose if you don't care about
upgradability, and save a few pennies per device.

For a purely business oriented manufacturer and the channel, the
proprietary nature of a product is an advantage - the cheaper the
product is to produce, the greater the profit margin, but also the
higher the end cost of the product (e.g. a complete Android slate vs.
just a new EOMA68 module), the higher the profit margin you can tag on
top. From this point of view, I can see the large-scale manufacturers
and distributors of certain classes of devices having a resistance to
the concept of making things easily upgradable.

That, of course, is not to say that I don't think EOMA68 is likely to
become massively popular in some areas, e.g. smaller scale
manufacturers and those interested in making higher-quality products
with decent long-term supportability, high density servers, etc.

The problem is in figuring out who stands to lose from standardisation
like this and working around them.


    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.


In terms of peripheral devices, sure, that'd be great. But my
perception is that with ever more being integrated onto the SoC, it
won't make the problem go away completely. It's a step in the right
direction, but I don't think it addresses the entire scope of the
current problem.

As an example, last I checked, Tegra2 has PCIe support in the SoC, but
last I checked, nobody has actually managed to make this work in an
actual device. Granted, not an entirely relevant example for EOMA68
since that doesn't have enough pins to break out PCIe, but it does
illustrate the importance of the issue of kernel level support for SoC
builtins, vs. external components.

Ultimately, however, I can see one benefit from EOMA68 in this regard
- it is inevitably going to give a big boost to well supported SoCs
because it is likely that EOMA68 cards will be much more likely to be
implemented using those SoCs. On the downside, some of the smaller,
more GPL violating SoC vendors are likely to go out of business, but
hopefully most will just start to be more GPL compliant in order to
not put their SoCs at a disadvantage in terms of likelyhood EOMA68
implementations. Note: that puts some of those more resistant-to-GPL
small manufacturers on the list of entities that will need to be
"worked around" due to them potentially standing to lose something
from a move away from proprietary implementations.


        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.


And you just hit the nail squarely on the head. This attitude prevails
far and wide in the SoC consumer electronics world, from what I can
tell. Devices are treated as throw-away both:
1) by the consumers who get them cheap enough that they can afford to
not worry about it (the attitudes, are, thankfully, changing slowly in
times of decline in economic prosperity, but this is offset by greater
propensity for buying something that is cheap over something that is
good).
and
2) the manufacturers, a lot of whom seem to be of the sort that set up
in a shed in China, build a few tens of thousands of devices, put them
in a shipping container, and are long dissolved and gone by the time
the devices arrive to the end market. Those manufacturers stand to
gain nothing at all by making standards compliant devices because they
have no intention of being around to support the device once it leaves
the factory.


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


Retorted to this point on the list.


        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.


Yup. A good summary of the point I was making above. :)


      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?


I'm not sure I quite see the distinction. How much of the kernel level
support is actually focused on the things that are _outside_ of the
SoC?


      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.


I think this is just coming across wrong - it sounds like you are
proposing addressing the issue of proprietary binary kernels with a
proprietary binary kernel for each EOMA68 SoC. Same situation, albeit
with fewer SoCs to support. Not saying that wouldn't be an improvement
(although all the other SoC vendors going out of business would reduce
competition and drive up prices, which would be a bad thing).

Anyway, you may want to clarify that point. :)