Request review of device tree documentation

[Nicolas Pitre]

On Wed, 16 Jun 2010, Mike Rapoport wrote:
> Mitch Bradley wrote:
> > One counterargument, of course, is that "there is a better way".  But it is
> > only "better" under a cost function that values things differently than the
> > vendors value them.  Were that not so, the vendors would gladly use the
> > "better" way and not be tempted to use the objectionable feature. (Unless,
> > of course, the vendors are just ignorant or unskilled - but I generally find
> > that different cost functions cause more disconnects than lack of ability.)
> 
> It's hardly arguable that Linux community and decision makers at chip vendor
> companies use different cost functions. But it's not that obvious that vendors
> cost functions based on well established _technical_ analysis.
> Many vendors try to use the same code base for several operating systems. From
> the high level perspective it sounds logical: use the same core functionality
> and thin adaptation layers to fit the core functionality into several OSes.
> But in reality, developing the OS abstraction layer and "thin" adaptation
> layers may become more expensive than developing each OS support from scratch.
> Besides, such code becomes a real mess after a while, and it's maintainability
> is very questionable.

The cost function _is_ different for the Linux community and decision 
makers at chip vendor companies. I know that for having worked long 
enough at a prominent chip vendor already.

Those vendors want to ship a product and be first on the market before 
the competitors do.  They grab a kernel tree, fit in their existing HAL 
as quickly as they can, so that they are able to demo the new chip to 
potential customers even before moving to full production.  And if the 
HAL fitting work has been done into last year's kernel already, then 
they will simply reuse that kernel to minimize the effort further as in 
theory only the HAL part needs to be swapped with the new one (doesn't 
matter if last year's kernel was itself already based on a kernel from 
the year before).  Once the software appears to work, they send it to 
customers and forget about it as they move to the next chip design.  So 
here, the cost is directly related to bring-up time, and quick (or big) 
ugly software hacks are more than a convenience but rather a necessity 
if you want to win the race.

People from the Linux community care about totally different things. The 
most important factor here is _long term_ maintainability.  It is 
important that the code be clean, use a uniform coding style, and follow 
common interfaces.  This is so because the cost function here is 
directly related to the difficulty for the Linux community to evolve the 
kernel with generic improvements and new features.  If each driver has a 
different style, or rely on a different HAL, then it quickly becomes 
extremely expensive to update those drivers along with the generic 
improvements.  And if the HAL is in binary form only, or stuck behind 
some unalterable BIOS-like calls or firmware API, then it may even be 
impossible to update those drivers as the execution context assumed by 
the HAL firmware may not be guaranteed anymore (think about UP vs SMP, 
different preemption modes, different realtime kernel modes, etc.)  And 
of course it is impossible to anticipate what execution context and 
requirements the kernel might need in the future, hence this can't be 
provisioned for (and much less validated) into the HAL design in advance 
(and see above why it is next to hopeless to expect vendors to update 
their HAL for old products in a timely fashion).

So there *is* indeed a big difference between both points of view.  And 
sometimes the imperatives from each group are in total conflict.

> > Which of course raises the question:  How does the Linux community view such
> > SoC vendors?  Are they embraced and eagerly supported, or (either openly or
> > secretly) viewed as a nuisance?  How does the widespread objection to
> > something that such vendors "would make extensive use of" mesh with that
> > view?
> 
> I cannot tell for the entire Linux community, but from what I know, such
> vendors are not much welcomed in the community.

And the reverse is also true: those vendors are not amenable to more 
openness and early community involvement which could help them get to 
market with "community acceptable" support for their products due to 
NDAs and such, or simply because of the perception that the Linux 
community is putting too much value on "expendable software".  It is way 
too common to hear from hardware designers that "software is cheap"... 
which is not quite the case in the end.  That's a real pity.


Nicolas