The embedded Linux nightmare - an epilogue
Posted May 2, 2007 23:14 UTC (Wed) by roelofs
Parent article: The embedded Linux nightmare - an epilogue
It is undisputed that kernel versions need to be frozen for product releases, but it can be observed that those freezes are typically done very early in the development cycle and are kept across multiple versions of the product or product family. These freezes, which are the vain attempt to keep the existing procedures alive ...
That's a tad simplistic--sometimes the reason is as innocuous as "minimize your variables." For example, when we encounted bugs on a project on which I worked several years ago, it was rarely obvious whether it was an application bug, a toolchain bug (GCC/binutils/glibc), a kernel bug, or a hardware bug (CPU itself or support chips/boards, each of which may be literally unique due to manufacturing flaws). Indeed, over the course of the project we found examples of each flavor--and at least one of the kernel bugs wasn't in driver code; it was in regular, mainline code (albeit infrequently used mainline code).
That said, we did upgrade kernels at least two or three times (I recall at least 2.4.7, 2.4.14, and 2.4.18), and for all I know, there were further updates before the product(s) shipped. But it's an overstatement to solely blame a desire to "keep the existing procedures alive"--unless, of course, one of the procedures in question is the scientific method.
Bigger players in the embedded market apparently have budgets large enough to ignore the benefits of working with the community and just concentrate on their private forks.
I suspect it's less an issue of enjoying large budgets than of suffering large bureaucracies. ;-) Barring a champion with enough authority to make his or her own decisions on behalf of the company (rare!), it can be extremely difficult even to find out whose department has such authority, much less to make contact and convince her/him/them. Even my implication that there's a single such department is questionable; it could easily involve multiple departments/divisions/management chains, not to mention lawyers and perhaps even one or more third parties. Ten iterations of review/revise before acceptance into the mainline kernel is nothing compared to that level of brutality. :-(
to post comments)