I am not sure you are right.

For example, would Cavium be willing to provide a few years ago all their crypto additional instructions to the competition? Will Tilera be willing to provide to their competition the exact implementation of their distributed cache coherency mechanism? Would any vendor be willing to provide even the information about adding a particular hardware offload engines to their competition, less details on how it works?

Let us say that a vendor quadrupled their TLB size, will they be willing to give that fact out to their competition ahead of time? Etc, etc.

Chip vendors work on their next generation chip for very long time, and they definitely don’t want for the competition to know about planned features, some of them deeply affecting Linux modules.
The only way I see it working is that chip vendors would work only on their proprietary distribution or a snapshot of a standard distribution, and will provide all the information only when the chip is out (and even that is the question mark). That would mean delay of software availability to board designers and system integrators.

I do not believe a CPU vendor has to release all details of a chipset to a Linux distribution provider. What we are hoping from an ideal solution is that Linux vendors are providing a generic compilation and packaging solution which can be easily *customized* and cross compiled. Kernel and cross compilers should also be part of the combinations.

Right now, most embedded Linux distributions are not made of “innovations”. There is more innovation on Dekstop/Server Linux distributions (Redhat-Fedora-Mandriva-etc vs Ubuntu-Debian-etc): SPICE from Redhat, KVM with its userland management tools, GUIs, etc.

The embedded innovations are mainly from the CPU vendors (debuggers, gcc upgrades, Kernel optimizations, BSP optimizations, etc.).

Maybe, an ideal embedded solution from an embedded Linux vendor would mean:

– to be able to use any toolchain, which is best optimized by the CPU vendors. So, typically for a same target, two tool chains would be useable with a same embedded Linux distribution: a default one from the Linux vendor and a CPU vendor one.
– to be able to use any Linux kernel version within a range of kernels. It does not make sense to link a kernel version with a Linux distribution. For instance, most userland packages (apache for instance) can work with any Linux kernels. Some cannot work, but only for compilation issues! Once any Linux kernel can be used, some kernels can be from the CPU vendors with the most optimized BSPs and some kernels can be from the Linux vendors.
– to provide profiling (oprofile, papi, etc.), coverage tools, debuggers that are closed to the CPU’s capabilities.
– to push forward Linux optimizations into the main Linux’s git trees (RCU optimisations, system call latency, SMP locking, 32/64 bits ABIs with any combinations); it means to become a visible actor of key Open Source components (glibc, gcc, Kernel).

1) Will these two vendors provide full support for competing solutions with the same priority as their own, or the support for other processors will become a background task, running when there are extra cycles available from their own CPU support?
2) Will other vendors (for example, Freescale) provide their competitors Intel and Cavium with potentially sensitive information about their new upcoming processors?

My biggest concern would actually be the second question, because it requires strict internal firewall inside Intel and Cavium to make sure that there is no sensitive information transfer within their organizations.